Event-Driven Microservices: Choreography vs Orchestration

When building event-driven microservices, developers frequently write code that updates a database and publishes an event in sequence:

typescript
Copy
// ❌ THE DUAL-WRITE DISASTER ANTI-PATTERN
async function placeOrder(orderData: OrderDto) {
  // Step 1: Save order to database
  await db.orders.insert(orderData);

  // Step 2: Publish event to Kafka
  await kafkaProducer.send('order-created', orderData);
}

Why Dual-Writes Cause Catastrophic Inconsistencies:

1. Crash After DB Commit: If the server container crashes (or loses network connectivity to Kafka) immediately after line 4, the order is saved in the database, but the event is never published. The billing and inventory services never receive the event, resulting in an unfulfilled zombie order.
2. Reverse Order Failure: If you publish to Kafka first and then save to the database, Kafka succeeds, but a database constraint violation fails line 4. Downstream services charge the user's credit card for an order that does not exist in the database!
3. No Distributed 2PC Support: Traditional ACID transactions cannot span both a relational database and an Apache Kafka cluster.