Messaging Patterns in Distributed Systems

TL;DR

Messaging patterns enable asynchronous communication between distributed system components through intermediaries like message brokers and event buses. Instead of direct service-to-service calls, producers send messages to queues or topics that consumers read independently, enabling loose coupling, fault tolerance, and independent scaling. This foundational pattern underpins event-driven architectures at companies like Netflix, Uber, and LinkedIn.

Cheat Sheet: Synchronous = immediate response required (REST, gRPC). Asynchronous = fire-and-forget or eventual consistency (message queues, pub/sub). Use messaging when you need: decoupling, buffering, fanout, or guaranteed delivery. Trade-off: added complexity and eventual consistency.

Why This Matters

In a monolithic application, components communicate through direct function calls with immediate responses. This tight coupling works fine until you need to scale different parts independently, handle failures gracefully, or integrate with external systems that might be temporarily unavailable. Messaging patterns solve these problems by introducing an intermediary that decouples producers from consumers.

Consider Netflix’s video encoding pipeline. When a user uploads a video, dozens of operations must happen: virus scanning, thumbnail generation, encoding in multiple formats, subtitle processing, and CDN distribution. If these were synchronous API calls, a single slow step would block everything, and a failure in thumbnail generation would prevent encoding from starting. Instead, Netflix uses messaging: the upload service publishes an event, and independent workers consume it at their own pace. If thumbnail generation fails, encoding still proceeds. If encoding is slow, it doesn’t block uploads.

In system design interviews, messaging patterns demonstrate architectural maturity. Junior engineers often default to synchronous REST APIs for everything. Senior engineers recognize when asynchronous communication enables better scalability, resilience, and operational flexibility. The interviewer wants to see you understand not just “what is a message queue” but “when does messaging solve problems that synchronous communication cannot.”

Messaging is particularly critical for three interview scenarios: designing event-driven systems (notification services, activity feeds), building resilient workflows (payment processing, order fulfillment), and handling high-throughput data ingestion (analytics pipelines, log aggregation). Companies like Uber process millions of trip events per minute through messaging systems—understanding these patterns is essential for senior roles.

Synchronous vs. Asynchronous Communication: Netflix Video Upload Example

graph LR
    subgraph Synchronous Approach - Blocking
        U1[Upload Service]
        V1[Virus Scanner]
        T1[Thumbnail Gen]
        E1[Encoder]
        U1 --"1. Scan (waits)"--> V1
        V1 --"2. Generate (waits)"--> T1
        T1 --"3. Encode (waits)"--> E1
        E1 -."4. Response".-> U1
    end
    subgraph Asynchronous Approach - Non-Blocking
        U2[Upload Service]
        Q[Message Queue]
        V2[Virus Scanner]
        T2[Thumbnail Gen]
        E2[Encoder]
        U2 --"1. Publish event"--> Q
        U2 -."2. Immediate response".-> U2
        Q --"3. Consume independently"--> V2
        Q --"4. Consume independently"--> T2
        Q --"5. Consume independently"--> E2
    end

Synchronous communication creates tight coupling where each step blocks the next, causing cascading delays and failures. Asynchronous messaging decouples services—the upload service returns immediately while independent workers process tasks in parallel at their own pace.

The Landscape

The messaging landscape spans three major paradigms, each with distinct characteristics and use cases. Understanding this taxonomy helps you choose the right tool for each problem.

Point-to-Point Queues represent the simplest messaging model. A producer sends a message to a queue, and exactly one consumer receives it. Think of this as a work distribution system: when Stripe needs to process a payment, it enqueues the request, and one of many payment workers picks it up. Amazon SQS and RabbitMQ queues exemplify this pattern. The key property is single-consumer semantics—once a message is consumed, it’s gone from the queue. This works perfectly for task distribution but poorly for broadcasting information to multiple interested parties.

Publish-Subscribe (Pub/Sub) Systems invert this model. A producer publishes a message to a topic, and every subscribed consumer receives a copy. When Twitter processes a tweet, it publishes to a topic, and multiple consumers react: one updates timelines, another triggers notifications, a third feeds the search index, and a fourth archives to data warehouses. Google Cloud Pub/Sub and Amazon SNS implement this pattern. The critical difference from queues is fanout—one message reaches many consumers independently.

Event Streaming Platforms like Apache Kafka and Amazon Kinesis combine aspects of both while adding durability and replay capabilities. Messages (events) are stored in an ordered log that multiple consumers can read at different speeds. LinkedIn uses Kafka to stream billions of events daily—activity tracking, metrics, database change logs. Unlike traditional queues where messages disappear after consumption, Kafka retains events for days or weeks, enabling new consumers to process historical data and existing consumers to replay events after failures.

Message Brokers vs. Event Buses represent an architectural distinction. Message brokers (RabbitMQ, ActiveMQ) focus on reliable message delivery with features like routing, priority queues, and transactional semantics. Event buses (EventBridge, Azure Event Grid) emphasize event routing and filtering, often with schema registries and event catalogs. The line blurs in practice—Kafka acts as both—but the conceptual difference matters in interviews.

The landscape also includes specialized messaging systems: Redis Pub/Sub for low-latency ephemeral messaging, NATS for cloud-native microservices, and Pulsar for multi-tenancy. Each optimizes different trade-offs in the CAP theorem space, delivery guarantees, and operational complexity.

Messaging Paradigms: Point-to-Point, Pub/Sub, and Event Streaming

graph TB
    subgraph Point-to-Point Queue
        P1[Producer]
        Q1[Queue]
        C1[Consumer 1]
        C2[Consumer 2]
        P1 --"Send message"--> Q1
        Q1 --"Exactly one receives"--> C1
        Q1 -."OR".-> C2
    end
    subgraph Publish-Subscribe
        P2[Publisher]
        T[Topic]
        S1[Subscriber 1<br/>Timeline]
        S2[Subscriber 2<br/>Notifications]
        S3[Subscriber 3<br/>Search Index]
        P2 --"Publish event"--> T
        T --"Copy 1"--> S1
        T --"Copy 2"--> S2
        T --"Copy 3"--> S3
    end
    subgraph Event Streaming - Kafka
        P3[Producer]
        L[Event Log<br/>Partitioned & Durable]
        CG1[Consumer Group A<br/>Real-time]
        CG2[Consumer Group B<br/>Analytics]
        P3 --"Append events"--> L
        L --"Read at offset 100"--> CG1
        L --"Read at offset 50"--> CG2
        L -."Retained for replay".-> L
    end

Point-to-point queues distribute work to exactly one consumer (Stripe payment processing). Pub/sub broadcasts events to all subscribers (Twitter tweet fanout). Event streaming combines both with durable logs that multiple consumer groups can read at different speeds (LinkedIn activity tracking).

Key Areas

Synchronous vs. Asynchronous Communication forms the foundational distinction in distributed systems. Synchronous communication (REST, gRPC) means the caller waits for a response, blocking until the operation completes. This provides immediate feedback and simpler error handling but creates tight coupling and cascading failures. When Uber’s rider app requests a price estimate, it needs an immediate answer—synchronous makes sense. Asynchronous communication means the sender continues without waiting, receiving confirmation later or not at all. This enables loose coupling and resilience but complicates error handling and debugging. When Uber completes a trip, it asynchronously publishes events for billing, driver ratings, and analytics—these can happen independently without blocking trip completion. The choice fundamentally shapes your system’s scalability and failure modes.

Message Delivery Guarantees determine reliability characteristics. At-most-once delivery (fire-and-forget) is fast but messages may be lost—acceptable for metrics where occasional loss doesn’t matter. At-least-once delivery guarantees messages arrive but may duplicate—Stripe’s payment processing handles this with idempotency keys. Exactly-once delivery (or effectively-once) is the holy grail but requires distributed transactions or sophisticated deduplication. In interviews, discussing delivery guarantees shows you understand the trade-offs between performance, complexity, and correctness. Real systems often use at-least-once with idempotent consumers rather than fighting for true exactly-once.

Message Ordering and Partitioning become critical at scale. Within a single queue or partition, messages typically maintain FIFO order. But when you partition for parallelism—splitting messages across multiple queues based on user ID or region—you lose global ordering. Kafka guarantees order within a partition but not across partitions. Instagram’s feed generation must process a user’s actions in order (follow, then unfollow), so it partitions by user ID, ensuring one user’s events stay ordered. Understanding when you need ordering and how partitioning affects it separates mid-level from senior engineers.

Choreography vs. Orchestration represents two patterns for coordinating multi-step workflows. Choreography is decentralized: each service listens for events and decides what to do next. When Netflix encodes a video, the upload service publishes “VideoUploaded,” the scanner publishes “ScanComplete,” and the encoder listens for scan events. No central coordinator exists. Orchestration is centralized: a workflow engine explicitly calls each step. AWS Step Functions exemplifies this—a state machine explicitly invokes Lambda functions in sequence. Choreography scales better and avoids single points of failure but makes workflows harder to understand and debug. Orchestration provides visibility and easier error handling but creates a coordination bottleneck. The choice depends on workflow complexity and team structure.

Backpressure and Flow Control prevent fast producers from overwhelming slow consumers. Without backpressure, a sudden traffic spike fills queues until memory exhausts or messages are dropped. Reactive Streams and gRPC implement explicit backpressure where consumers signal their capacity. Message brokers use queue depth limits and consumer prefetch settings. Netflix’s encoding pipeline monitors queue depths and scales workers dynamically. In interviews, mentioning backpressure shows operational maturity—you’re thinking about what happens when things go wrong, not just the happy path.

Message Delivery Guarantees and Idempotency

graph TB
    subgraph At-Most-Once - Fire and Forget
        P1[Producer] --"Send"--> B1[Broker]
        B1 -."May be lost".-> C1[Consumer]
        C1 --> R1["✓ Fast<br/>✗ Data loss possible<br/>Use: Metrics, logs"]
    end
    subgraph At-Least-Once - Retry Until Ack
        P2[Producer] --"Send + Retry"--> B2[Broker]
        B2 --"Deliver"--> C2[Consumer]
        C2 --"Process"--> I[Idempotency Check]
        I --"First time"--> D[Execute]
        I -."Duplicate".-> S[Skip]
        C2 --"Ack after processing"--> B2
        D --> R2["✓ No loss<br/>✗ Duplicates<br/>Use: Payments with idempotency keys"]
    end
    subgraph Exactly-Once - Distributed Transaction
        P3[Producer] --"Transactional send"--> B3[Broker]
        B3 --"Deliver once"--> C3[Consumer]
        C3 --"Process + Commit"--> DT[Distributed Transaction]
        DT --> R3["✓ No loss or duplicates<br/>✗ Complex, slower<br/>Use: Critical financial workflows"]
    end

At-most-once is fast but lossy (acceptable for metrics). At-least-once guarantees delivery but requires idempotent consumers to handle duplicates (Stripe’s approach). Exactly-once is theoretically ideal but requires complex distributed transactions—most systems use at-least-once with idempotency instead.

Pattern Selection Guide

Choosing the right messaging pattern depends on your use case characteristics. Start by asking: do you need a response? If yes, consider synchronous communication (REST, gRPC) unless you can use request-reply messaging patterns. If no, proceed to asynchronous options.

Next, consider fanout requirements. If exactly one consumer should process each message (work distribution), use point-to-point queues like SQS or RabbitMQ. If multiple consumers need the same message (event notification), use pub/sub like SNS or Kafka topics. If you need both patterns or might add consumers later, Kafka’s consumer groups provide flexibility—multiple groups can read the same topic, and within each group, messages are distributed.

Evaluate durability needs. For ephemeral messages where loss is acceptable (real-time metrics, presence updates), Redis Pub/Sub or NATS suffice. For critical business events requiring guaranteed delivery (financial transactions, order processing), choose durable brokers like RabbitMQ with persistent queues or Kafka with replication. If you need to replay historical events or build new consumers that process past data, Kafka’s log retention is essential.

Consider ordering requirements. If global ordering matters and throughput is modest, a single queue works. If you need high throughput and can partition logically (by user, tenant, or region), use Kafka partitions or SQS FIFO queues with message group IDs. If ordering doesn’t matter, standard SQS queues provide maximum throughput and simplicity.

Finally, assess operational complexity. Managed services like SQS, SNS, and EventBridge reduce operational burden but offer less control. Self-hosted Kafka or RabbitMQ provide more features and flexibility but require expertise to operate reliably. For startups, start simple with managed queues. For companies at scale, the operational investment in Kafka often pays off through superior throughput and flexibility.

Messaging Pattern Selection Decision Tree

flowchart TB
    Start[Need to communicate<br/>between services?]
    Start --> Sync{Need immediate<br/>response?}
    Sync -->|Yes| SyncChoice[Use REST/gRPC<br/>Synchronous API]
    Sync -->|No| Fanout{Multiple consumers<br/>need same message?}
    Fanout -->|No - Single consumer| WorkDist[Point-to-Point Queue<br/>SQS, RabbitMQ]
    Fanout -->|Yes - Broadcast| PubSub{Need message<br/>replay/history?}
    PubSub -->|No - Ephemeral| SimplePubSub[Simple Pub/Sub<br/>SNS, Redis Pub/Sub]
    PubSub -->|Yes - Durable| Ordering{Need strict<br/>message ordering?}
    Ordering -->|Yes - Global order| SingleQueue[Single Queue/Partition<br/>SQS FIFO, Kafka single partition]
    Ordering -->|No - Can partition| Throughput{High throughput<br/>required?}
    Throughput -->|Yes - Millions/sec| Kafka[Event Streaming<br/>Kafka, Kinesis]
    Throughput -->|No - Moderate| ManagedQueue[Managed Queue<br/>SQS Standard]
    WorkDist --> Ops{Self-host or<br/>managed service?}
    Ops -->|Managed - Less ops| AWS[AWS: SQS/SNS<br/>GCP: Pub/Sub]
    Ops -->|Self-host - More control| RabbitMQ[RabbitMQ<br/>ActiveMQ]

Start by determining if you need synchronous responses. For async communication, choose point-to-point for work distribution or pub/sub for fanout. Consider replay needs, ordering requirements, throughput, and operational complexity to select between simple queues, managed pub/sub, or event streaming platforms like Kafka.

How Things Connect

The messaging patterns in this module build on each other in a logical progression. This overview establishes the foundational concepts—asynchronous communication, message brokers, and delivery guarantees—that every other pattern assumes. Understanding these fundamentals is prerequisite for the specific patterns.

The Queue-Based Load Leveling pattern (see queue-based-load-leveling) applies messaging to smooth traffic spikes by buffering requests in queues. It’s the most direct application of basic queue concepts. Priority Queue (see priority-queue) extends this by adding message prioritization, useful when some work is more urgent than others.

Publisher-Subscriber (see publisher-subscriber) shifts from point-to-point to fanout, enabling event-driven architectures where multiple services react to the same events. This pattern is foundational for microservices communication. Claim Check (see claim-check) optimizes pub/sub by separating large payloads from message metadata, solving the problem of message size limits.

The Choreography pattern (see choreography) uses pub/sub for decentralized workflow coordination, while Competing Consumers (see competing-consumers) addresses scaling message processing by parallelizing consumption across multiple workers.

These patterns aren’t mutually exclusive—production systems combine them. Netflix’s video pipeline uses pub/sub for event distribution, queue-based load leveling to handle upload spikes, competing consumers for parallel encoding, and choreography to coordinate the overall workflow without a central orchestrator. Understanding how patterns compose is what separates good system designs from great ones.

The relationship to other modules is equally important. Messaging patterns depend heavily on infrastructure choices covered in the Infrastructure module—whether you use Kafka, RabbitMQ, or cloud-native services affects pattern implementation. The Data Management Patterns module explores how messaging enables eventual consistency through event sourcing and CQRS. The Reliability Patterns module shows how messaging contributes to fault tolerance through retry mechanisms and dead letter queues.

Real-World Context

Understanding how companies actually use messaging in production grounds theoretical knowledge in practical reality. The scale and complexity vary dramatically, but patterns remain consistent.

Netflix operates one of the world’s largest Kafka deployments, processing over 700 billion events daily. Their architecture uses messaging for everything from A/B test assignments to video encoding workflows. When a user presses play, that event triggers a cascade: viewing history updates, recommendation model retraining, content popularity tracking, and billing calculations. Each consumer processes events independently at its own pace. Netflix’s key insight: messaging enables them to add new consumers without touching existing systems. When they built their real-time anomaly detection system, they simply added a new Kafka consumer group—no changes to producers required.

Uber uses messaging to coordinate their complex marketplace. When a rider requests a trip, the request goes into a queue that the matching service consumes. Once matched, events flow through Kafka: trip started, driver arrived, trip completed. Each event triggers multiple reactions—billing, driver ratings, fraud detection, analytics. Uber’s challenge is maintaining ordering for critical workflows (a trip can’t complete before it starts) while allowing parallel processing for independent operations. They partition by trip ID to guarantee ordering within a trip while processing millions of trips concurrently.

LinkedIn built Kafka to solve their own messaging needs and open-sourced it. They use Kafka for activity tracking (every profile view, connection request, message), metrics collection, and database change data capture. Their key pattern: the same events feed both real-time systems (notifications, news feed) and batch analytics (data warehouse, machine learning). This dual use of event streams eliminates the need to build separate data pipelines for operational and analytical workloads.

Stripe uses SQS and SNS for payment processing workflows. When a payment is initiated, it enters a queue that workers consume. The workers handle retries, idempotency, and eventual consistency with external payment networks. Stripe’s architecture prioritizes correctness over speed—they use at-least-once delivery with idempotency keys rather than risking message loss. Their dead letter queues capture failed payments for manual review, ensuring no transaction is silently dropped.

The common thread across these companies: messaging enables them to build systems that are loosely coupled, independently scalable, and resilient to failures. They accept the complexity of eventual consistency and operational overhead because the architectural benefits—particularly the ability to evolve systems without coordinated deployments—are worth it at scale.

Netflix Video Pipeline: Choreographed Event-Driven Architecture

graph LR
    Upload[Upload Service] --"1. VideoUploaded event"--> Kafka[Kafka Topics]
    Kafka --"2. Consume event"--> Scanner[Virus Scanner]
    Scanner --"3. ScanComplete event"--> Kafka
    Kafka --"4. Consume event"--> Thumbnail[Thumbnail Generator]
    Kafka --"4. Consume event"--> Encoder[Video Encoder]
    Thumbnail --"5. ThumbnailReady event"--> Kafka
    Encoder --"6. EncodingComplete event"--> Kafka
    Kafka --"7. Consume event"--> CDN[CDN Distribution]
    Kafka --"8. Consume all events"--> Analytics[Analytics Pipeline]
    Kafka --"9. Consume all events"--> Recommendations[Recommendation Engine]
    subgraph Independent Consumers - No Coordination
        Scanner
        Thumbnail
        Encoder
        CDN
        Analytics
        Recommendations
    end

Netflix processes 700+ billion events daily through Kafka using choreography—no central orchestrator. Each service publishes events and subscribes to relevant topics. New consumers (like the recommendation engine) can be added without modifying existing services, enabling independent team scaling and system evolution.

---

Interview Essentials

Mid-Level

At the mid-level, demonstrate you understand the basic messaging patterns and when to use them. Explain the difference between synchronous and asynchronous communication with concrete examples. Describe how a message queue enables decoupling between services and handles traffic spikes through buffering. Show you know the common delivery guarantees (at-most-once, at-least-once, exactly-once) and can discuss trade-offs.

When designing a system, identify opportunities for messaging naturally. If designing a notification service, suggest using pub/sub so multiple channels (email, SMS, push) can consume the same events. If designing an order processing system, propose queues to decouple order placement from payment processing. The key is showing messaging isn’t just a technology choice but an architectural pattern that solves specific problems.

Be ready to discuss basic failure scenarios: what happens if a consumer crashes mid-processing? How do you prevent message loss? What is a dead letter queue and when would you use one? You don’t need deep expertise in specific technologies, but you should understand the conceptual challenges and common solutions.

Senior

Senior engineers must demonstrate nuanced understanding of messaging trade-offs and experience with production systems. Discuss delivery guarantees in depth: why exactly-once is hard to achieve, how idempotency enables at-least-once processing, and when eventual consistency is acceptable. Explain message ordering challenges when partitioning for scale and how to design around them.

Show architectural judgment in pattern selection. Compare choreography vs. orchestration for workflow coordination, explaining when each is appropriate. Discuss how to handle backpressure when consumers can’t keep up with producers. Explain the trade-offs between managed services (SQS, SNS) and self-hosted solutions (Kafka, RabbitMQ) in terms of operational complexity, cost, and capabilities.

Bring production experience to the conversation. Describe how you’ve debugged messaging systems—tracing messages through distributed systems, handling poison messages, monitoring queue depths. Discuss capacity planning: how do you size queues and provision consumers? What metrics matter (queue depth, consumer lag, processing time)? How do you handle schema evolution as message formats change?

Address the operational challenges interviewers care about: How do you ensure messages aren’t lost during deployments? How do you handle consumer rebalancing in Kafka? What’s your strategy for dead letter queue processing? These details show you’ve operated messaging systems at scale, not just read about them.

Staff+

Staff-plus engineers must demonstrate strategic thinking about messaging architectures across an organization. Discuss how messaging patterns enable organizational scaling—how teams can work independently when they communicate through well-defined events rather than direct API calls. Explain the trade-offs between building on a single messaging platform (operational simplicity, consistent patterns) vs. choosing best-of-breed tools for different use cases (optimization, flexibility).

Show deep understanding of consistency models and their business implications. Explain how event sourcing and CQRS use messaging to achieve eventual consistency while maintaining audit trails. Discuss compensating transactions for handling failures in distributed workflows. Address the CAP theorem implications—how messaging systems choose between consistency and availability, and how those choices affect application design.

Bring architectural patterns from multiple companies. Compare Netflix’s Kafka-centric architecture with Stripe’s SQS-based approach, explaining why different business models and scale requirements lead to different choices. Discuss how messaging enables zero-downtime deployments through consumer versioning and backward-compatible schemas.

Address the hardest problems: How do you migrate from synchronous to asynchronous communication without downtime? How do you ensure data consistency across services that communicate via events? What’s your approach to distributed tracing in event-driven systems? How do you handle cascading failures when message processing triggers more messages? These questions reveal whether you can architect complex distributed systems, not just implement features.

Common Interview Questions

When would you choose a message queue over direct API calls? (Answer: when you need decoupling, buffering, or guaranteed delivery. Queues enable async processing, handle traffic spikes, and allow producers/consumers to scale independently. Use APIs when you need immediate responses or strong consistency.)

Explain the difference between a message queue and pub/sub. (Answer: Queues deliver each message to exactly one consumer—work distribution. Pub/sub delivers each message to all subscribers—event notification. Kafka blurs this with consumer groups: multiple groups see all messages, but within a group, messages are distributed.)

How do you handle message processing failures? (Answer: Retry with exponential backoff, use dead letter queues for persistent failures, implement idempotency to handle duplicate processing, monitor and alert on DLQ depth, have runbooks for manual intervention.)

What are the trade-offs of eventual consistency in messaging systems? (Answer: Pros: better availability, performance, and scalability. Cons: complex application logic, harder debugging, potential for temporary inconsistencies. Acceptable for many use cases like social feeds, problematic for financial transactions.)

How do you ensure message ordering at scale? (Answer: Partition by entity ID (user, order) to maintain ordering within an entity while parallelizing across entities. Accept that global ordering doesn’t scale. Use sequence numbers to detect out-of-order delivery.)

Red Flags to Avoid

Suggesting messaging for every communication without considering synchronous alternatives—shows lack of judgment about trade-offs

Not understanding delivery guarantees or claiming exactly-once is easy—reveals lack of production experience

Ignoring operational complexity of self-hosted messaging systems—underestimates what it takes to run Kafka reliably

Not discussing idempotency when talking about at-least-once delivery—misses critical implementation detail

Treating messaging as just a technology choice rather than an architectural pattern that shapes system design

Not considering monitoring, alerting, and debugging challenges in async systems—focuses only on happy path

Suggesting Kafka for every use case without considering simpler alternatives like SQS—over-engineering

---

Key Takeaways

Messaging patterns enable asynchronous communication through intermediaries (queues, topics, brokers), decoupling producers from consumers for better scalability, resilience, and independent evolution. The trade-off is increased complexity and eventual consistency.

Choose point-to-point queues for work distribution (one consumer per message), pub/sub for event notification (all subscribers receive messages), and event streaming platforms like Kafka when you need durability, replay, and high throughput.

Delivery guarantees matter: at-most-once is fast but lossy, at-least-once requires idempotent consumers, exactly-once is hard to achieve. Most production systems use at-least-once with idempotency rather than fighting for true exactly-once.

Choreography (decentralized, event-driven coordination) scales better but is harder to debug. Orchestration (centralized workflow engines) provides visibility but creates bottlenecks. Choose based on workflow complexity and team structure.

Real-world systems like Netflix and Uber use messaging to process billions of events daily, enabling them to add new functionality by adding consumers without touching existing systems. This architectural flexibility is messaging’s greatest value at scale.

---