Your microservices aren’t failing under load. They’re failing under conversation.
Every sync call between services is a phone call that blocks the caller until someone picks up. Now imagine your system makes 47 of those calls to render a single page. That was Netflix’s reality before they rewired everything.
Here’s what nobody tells you about microservice communication: the pattern you pick matters more than the language you write it in.
There are 4 core communication patterns. Most teams only use one, and it’s the wrong one for 70% of their use cases.
<ol>
<li>POINT-TO-POINT (ONE-TO-ONE)</li>
</ol>
One producer, one consumer. A direct handoff. Think of it as a task queue: “Process this payment.” “Resize this image.”
<ul>
<li>AWS service: SQS.</li>
<li>Use it when: each message needs exactly one handler.</li>
</ul>
<ol>
<li>PUBLISH/SUBSCRIBE (ONE-TO-MANY)</li>
</ol>
One event, multiple consumers. Nobody needs to know who’s listening.
<ul>
<li>AWS service: SNS for simple fan-out. EventBridge when you need content-based filtering.</li>
<li>Use it when: one event triggers multiple independent reactions.</li>
</ul>
<ol>
<li>REQUEST-REPLY (SYNC OR ASYNC)</li>
</ol>
You ask a question. You need an answer.
Sync = API Gateway. Async = queue + correlation ID.
<ul>
<li>Use sync when the client literally cannot proceed without the data.</li>
<li>Use async for everything else.</li>
</ul>
<ol>
<li>BROADCAST (EVERYONE HEARS IT)</li>
</ol>
System-wide announcements. Config changes. Cache invalidation.
<ul>
<li>AWS service: SNS topic or EventBridge catch-all.</li>
<li>Use it when: the event affects the entire system.</li>
</ul>
THE PATTERN MOST PEOPLE GET WRONG: They default to sync request-reply for everything. REST calls between services. Tight coupling disguised as “simple architecture.” Netflix cut API response times by 58% (850ms → 357ms) by moving to async event-driven patterns with Kafka.
Quick decision framework:
→ Need exactly-once processing? Point-to-point (SQS)
→ Multiple services need to react? Pub/Sub (SNS or EventBridge)
→ Client needs data right now? Sync request-reply (API Gateway)
→ System-wide notification? Broadcast (SNS catch-all)
Stop defaulting to HTTP calls between services. Start asking: “Does the caller actually need to wait?” 90% of the time, the answer is no.
<img src="https://media.daily.dev/image/upload/s--8UQYrF16--/f_auto/v1774643508/ugc/content_54aa533d-880c-4979-9e24-bb64e19dacc0?_a=BAMAMiWQ0" alt="excalidraw-animation (1).gif">

Joud Awad

Microservice communication patterns are often misused, with teams defaulting to synchronous HTTP calls for everything. Four core patterns are outlined: point-to-point (SQS), publish/subscribe (SNS/EventBridge), request-reply (sync or async), and broadcast. A decision framework helps choose the right pattern: use sync only when the client truly cannot proceed without an immediate response, and async for everything else. Netflix's shift to async event-driven patterns with Kafka is cited as cutting API response times by 58%.

Communication Patterns in Microservices!