Service-to-Service Calls vs Event-Driven Architecture: A Decision Framework
Every microservices team hits the same fork in the road: should Service A call Service B directly, or should it publish an event and let Service B react? The answer shapes your system's coupling, failure modes, and operational complexity for years to come.
This isn't about picking a winner. Both patterns solve different problems, and mixing them poorly creates the worst of both worlds: tight coupling and debugging nightmares. Here's how to decide.
The Three Communication Patterns
Before we compare, let's define the field:
Direct service-to-service calls (synchronous RPC): Service A makes an HTTP/gRPC call to Service B and waits for a response. Think POST /orders returning {orderId: 123} immediately.
Job queues and workers (asynchronous tasks): Service A pushes work onto a queue (RabbitMQ, SQS, Redis) and moves on. A worker process pulls from the queue and executes the task. The caller doesn't wait, but there's still a clear producer-consumer relationship.
Event-driven flows (pub/sub): Service A publishes a domain event ("OrderPlaced") to a bus (Kafka, EventBridge, NATS). Zero or more subscribers react independently. The publisher has no idea who's listening.
When Direct Calls Make Sense
Use synchronous service calls when:
You need the answer now. A checkout flow can't complete without validating payment. The user is waiting. An HTTP call to your payment service returns success/failure in 200ms, and you render the confirmation page. Pushing this to an event stream adds latency and forces you to poll or implement webhooks—complexity with no benefit.
The operation is a query, not a command. Reading a user profile, fetching product details, checking inventory—these are lookups. Events model things that happened. Queries don't fit that mental model. Use REST or GraphQL.
Failure should block the caller. If Service B is down and the workflow can't proceed anyway, a synchronous call fails fast. The caller gets a 503, retries with backoff, or shows an error. With events, you've queued work that will fail later, potentially in a batch of thousands.
Your team is small. Two engineers maintaining four services don't need Kafka. The operational overhead of message brokers, schema registries, and distributed tracing across async boundaries costs more than the coupling of a few HTTP calls.
When Event-Driven Wins
Choose pub/sub when:
Multiple systems need to react, and the list changes. An "OrderPlaced" event might trigger inventory updates, email notifications, analytics logging, and fraud checks. Adding a new subscriber (say, a recommendation engine) doesn't require touching the order service. With direct calls, you're adding another HTTP client and another failure point.
You're modeling business events, not technical requests. Events capture what happened in domain language: "UserSignedUp", "PaymentFailed", "ShipmentDelivered". This creates an audit log and decouples the trigger (payment failed) from reactions (refund, notify customer, log to analytics). The payment service doesn't need to know about your email provider.
Temporal decoupling matters. A service publishing events doesn't care if subscribers are down. Kafka retains the event; consumers catch up when they restart. With synchronous calls, if the email service is down, your order service either fails or needs circuit breakers and retry logic.
You need to scale producers and consumers independently. A flash sale generates 10,000 "OrderPlaced" events per minute. Your inventory service can't process them that fast, but it doesn't need to—Kafka buffers them, and you scale up consumer instances to drain the backlog. With direct calls, the order service would time out waiting for inventory to respond.
The Hybrid Pattern: Jobs and Workers
Queues with workers sit between synchronous and event-driven:
- Like events: asynchronous, decoupled in time, buffered
- Like direct calls: one producer, one consumer, clear ownership
Use queues when you have expensive or failure-prone work (resizing images, sending emails, calling third-party APIs) that doesn't need an immediate response. The caller gets a job ID, the worker processes it, and you poll or webhook the result.
This is simpler than full pub/sub—no schema registry, no multi-team event contracts—but gives you retry logic, backpressure, and failure isolation.
Common Mistakes
Synchronous chains that should be events. Service A calls B, which calls C, which calls D. If D is slow, the user waits. If C is down, the whole chain fails. This screams for events: A publishes "X happened", and B/C/D react independently.
Events that should be queries. Publishing "GetUserRequest" events and waiting for "UserResponse" is RPC with extra steps. Just call the user service.
Mixing both without a clear boundary. Writes via events, reads via HTTP is a clean split. Random mixing based on "what felt right" creates cognitive load: engineers never know where to look.
A Simple Decision Tree
- Does the caller need the result to proceed? → Synchronous call
- Is this a read/query operation? → Synchronous call
- Will multiple services react to this, now or in the future? → Event-driven
- Is this expensive work that can happen later? → Job queue
- Does failure need to block the caller? → Synchronous call
- Otherwise → Default to events for writes, HTTP for reads
The Real Tradeoff
Synchronous calls are easier to build and debug. Events are easier to extend and scale. Choose based on where you are: a 3-person startup optimizing for shipping features picks HTTP. A 50-engineer org with multiple teams touching the same domain picks events to avoid coordination bottlenecks.
The worst architecture is the one that doesn't match your team's operational maturity. Kafka won't save you if you can't debug a distributed trace. Direct calls won't save you if every feature requires cross-team deploys.
Pick the pattern that fits your constraints today, and design boundaries clean enough to refactor tomorrow.