The default: synchronous REST

Most systems start with REST. Service A calls Service B, waits for the response, and moves on. It's simple, debuggable, and works, until latency adds up, or B goes down and A cascades.

When to go event-driven

| Signal | Action | |--------|--------| | P99 latency > 500ms on a critical path | Extract to async | | One service outage cascades to three others | Decouple with events | | Write throughput needs horizontal scale | Kafka + consumer groups | | Audit trail is a compliance requirement | Event sourcing |

The cost of async

You gain resilience and throughput. You lose:

• Immediate consistency (eventual only)
• Simpler debugging (distributed traces required)
• Transactional guarantees (saga patterns instead)

Our rule of thumb

Start synchronous. When a request hits 200ms P99 and the caller doesn't need the result to proceed, extract the side effect to an event. Keep the critical path synchronous.