Communication Patterns includes six types: message queues for reliable task processing, event buses for broadcasting to multiple subscribers, sync vs async handling for deciding when to wait, batch vs real-time for processing frequency, streaming for continuous data flow, and polling for systems that cannot push updates. The right choice depends on your latency requirements, reliability needs, and system complexity tolerance. Most systems combine multiple patterns. Message queues handle critical tasks. Event buses coordinate reactions. Streaming powers real-time dashboards.
Your checkout calls five APIs in sequence. Customer stares at a spinner for 10 seconds. Your competitor shows "Order Placed" in 200ms.
Your inventory syncs overnight. Customer orders at 9am. The product was sold out 12 hours ago. Now you have a support ticket.
Every time something happens, you have to update six other systems. Change one integration and three others break.
The way your systems talk to each other determines whether everything feels fast or frustratingly slow.
Part of Layer 1: Data Infrastructure - How data moves between systems.
Communication Patterns determine how your systems talk to each other. The wrong choice creates slow user experiences, lost messages, and systems that break when one piece fails. The right choice means data flows reliably without creating bottlenecks.
Most systems need more than one pattern. Queues for critical tasks. Pub/sub for notifications. Streaming for dashboards. Polling for external APIs. The question is not "which one?" but "which ones, and for what?"
Each pattern optimizes for different trade-offs. Choosing wrong means either slow experiences or unnecessary complexity.
Queues | Pub/Sub | Sync/Async | Batch/RT | Streaming | Polling | |
|---|---|---|---|---|---|---|
| Message Delivery | One consumer per message, guaranteed delivery | All subscribers get every message | Depends on implementation choice | Bulk transfer vs continuous flow | Continuous append-only log | Pull on schedule, no guarantees |
| Latency | Seconds to minutes (queued) | Near real-time (milliseconds) | Sync: immediate; Async: eventual | Batch: hours; Real-time: instant | Milliseconds to seconds | Depends on poll interval |
| Complexity | Moderate (need consumer, dead letter handling) | Higher (topic design, subscriber management) | Sync: low; Async: higher | Batch: low; Real-time: high | High (backpressure, replay, state) | Low (just schedule and check) |
| Best For | Reliable background tasks | Multi-system reactions | Deciding wait vs continue | Choosing processing frequency | Real-time visibility | External system sync |
The right choice depends on your latency requirements, reliability needs, and how many systems need to react. Answer these questions to find your starting point.
“I need to process tasks in the background without losing any”
Message queues store tasks until processed and guarantee delivery.
“Multiple systems need to react when something happens”
Event buses broadcast to all subscribers without the publisher knowing who is listening.
“I need to decide whether to wait for a response or continue”
Understanding this pattern helps you choose blocking vs non-blocking for each call.
“I need to choose how often to process incoming data”
This pattern helps you balance freshness against complexity and cost.
“I need real-time dashboards and instant visibility”
Streaming processes data continuously so you see changes as they happen.
“External systems do not push updates to me”
Polling checks for changes on a schedule when push is not available.
Answer a few questions to get a recommendation.
Communication patterns are not about the technology. They are about matching how information moves to how quickly you need to act on it.
Systems need to exchange information or coordinate actions
Choose the pattern that matches your latency, reliability, and coupling requirements
Data flows smoothly without creating bottlenecks or lost messages
When your dashboard shows yesterday numbers but your team needs to know what is happening now...
That is a streaming problem. Events flow through continuously so visibility happens in seconds, not hours.
When someone updates a record and five other systems need to know but you keep adding direct integrations...
That is an event bus problem. Publish once, let every interested system subscribe. Add new systems without changing the publisher.
When your checkout process calls six APIs in sequence and customers wait 10 seconds for confirmation...
That is a sync vs async problem. Wait for payment confirmation, but queue everything else for background processing.
When external platforms do not push updates and you rely on someone remembering to click "sync"...
That is a polling problem. Check automatically on a schedule so data stays current without manual effort.
Which of these sounds most like your current situation?
These mistakes seem small at first. They compound into slow systems, lost data, and frustrated users.
Move fast. Structure data “good enough.” Scale up. Data becomes messy. Painful migration later. The fix is simple: think about access patterns upfront. It takes an hour now. It saves weeks later.
Communication patterns are the methods systems use to exchange information. They determine whether systems wait for responses (synchronous) or continue immediately (asynchronous), whether messages go to one receiver or many, and how frequently data moves. Common patterns include message queues for reliable delivery, pub/sub for broadcasting events, and streaming for continuous data flow. The pattern you choose affects system speed, reliability, and complexity.
Choose based on your requirements: Use message queues when tasks must complete reliably and order matters. Use pub/sub (event buses) when multiple systems need to react to the same event. Use synchronous calls when you need the response before continuing. Use streaming when you need real-time updates. Use polling when external systems cannot push updates to you. Most real systems combine several patterns for different use cases.
Message queues deliver each message to exactly one consumer. They guarantee processing and maintain order. Pub/sub (publish/subscribe) delivers each message to all subscribers. When an order is placed, a queue processes it once. With pub/sub, inventory, shipping, email, and analytics all receive a copy and react independently. Queues are for tasks. Pub/sub is for notifications.
Use synchronous when you need the answer before continuing. Payment confirmation must complete before showing "Order Placed." Use asynchronous when you can continue without waiting. Sending welcome emails can happen in the background. The rule: if the user needs to know it worked immediately, wait. If it just needs to happen eventually, make it async and move on.
The biggest mistakes are: using one pattern for everything (different needs require different patterns), making everything synchronous because it is simpler (this creates slow, fragile systems), going real-time when batch processing would work (unnecessary complexity and cost), and forgetting error handling in async flows (failures become invisible). Match the pattern to the requirement, not the other way around.
Yes, most real systems do. A typical setup: synchronous API calls for immediate user responses, message queues for background task processing, pub/sub for event notifications across services, and polling for external system integration. The key is matching each use case to the right pattern. Critical paths get queues. Notifications get pub/sub. External APIs without webhooks get polling.
Batch processing collects data over time and processes it all at once (nightly reports, weekly syncs). Streaming processes each piece of data as it arrives (real-time dashboards, instant alerts). Batch is simpler, cheaper, and handles large volumes efficiently. Streaming provides immediate visibility but requires more infrastructure. Choose based on how fresh your data needs to be.
Polling asks "anything new?" repeatedly on a schedule. You control when to check but waste resources when nothing changes. Webhooks push updates to you immediately when something happens but require the external system to support them. Event buses broadcast to all subscribers in real-time. Use polling when the external system lacks webhooks. Use webhooks or event buses when push notifications are available.
Have a different question? Let's talk