# Messaging Patterns (/learn)



KubeMQ is a single message broker that supports four distinct messaging patterns — from fire-and-forget broadcasting to reliable point-to-point delivery to synchronous request-reply. This section is a learning track, not just a reference: it starts with vendor-neutral fundamentals, shows how KubeMQ implements each pattern, helps you pick and combine them, then composes them into real architectures.

One broker, four patterns, every use case.

## How to read this track [#how-to-read-this-track]

Work through it in order, or jump straight to the tier you need. Each step links to the next.

<Cards>
  <Card title="1 · Concepts" href="/learn/concepts" description="Start here. Vendor-neutral concepts — interaction styles, delivery guarantees, ordering & replay, scaling & flow, channels & routing — across 6 pages." />

  <Card title="2 · The Four Patterns" href="/learn/events" description="How KubeMQ implements those concepts: Events, Events Store, Queues, and RPC." />

  <Card title="3 · Choosing & Combining" href="/learn/guides/choosing-a-pattern" description="An interactive decision guide to pick the right pattern, plus how to route to several at once." />
</Cards>

<Callout type="info">
  **New to messaging?** Start with the [Concepts](/learn/concepts) — six short pages that explain the ideas every pattern is built on.
</Callout>

## The Four Patterns [#the-four-patterns]

<Cards>
  <Card title="Events" href="/learn/events" description="Fire-and-forget pub/sub with at-most-once delivery. Fastest pattern, no persistence." />

  <Card title="Events Store" href="/learn/events-store" description="Persistent pub/sub with replay from any point. Messages survive disconnections." />

  <Card title="Queues" href="/learn/queues" description="Point-to-point with guaranteed delivery, ack, DLQ, delay, and exactly-once processing." />

  <Card title="RPC (Commands & Queries)" href="/learn/rpc" description="Synchronous request-reply. Commands for writes, Queries for reads." />
</Cards>

## The Four Patterns at a Glance [#the-four-patterns-at-a-glance]

| Feature            | [Events](/learn/events) | [Events Store](/learn/events-store) | [Queues](/learn/queues) | [RPC](/learn/rpc) |
| ------------------ | ----------------------- | ----------------------------------- | ----------------------- | ----------------- |
| Direction          | Pub/Sub                 | Pub/Sub                             | Point-to-Point          | Request-Reply     |
| Persistence        | No                      | Yes (disk)                          | Yes (disk)              | No                |
| Delivery guarantee | At-most-once            | At-least-once                       | Exactly-once            | At-most-once      |
| Replay             | No                      | Yes (6 positions)                   | No                      | No                |
| Acknowledgment     | No                      | No                                  | Yes (manual)            | Yes (automatic)   |
| Ordering           | No                      | Yes (sequence)                      | Yes (FIFO)              | N/A               |
| Response           | No                      | No                                  | No                      | Yes               |
| Dead letter queue  | No                      | No                                  | Yes                     | No                |
| Delayed delivery   | No                      | No                                  | Yes                     | No                |
| Caching            | No                      | No                                  | No                      | Yes (queries)     |

## Which Pattern Should I Use? [#which-pattern-should-i-use]

<Callout type="info">
  Use the [interactive decision guide](/learn/guides/choosing-a-pattern) to find the right pattern for your use case.
</Callout>

| If you need...                                | Use                                 |
| --------------------------------------------- | ----------------------------------- |
| Lowest latency, message loss acceptable       | [Events](/learn/events)             |
| Pub/sub with no message loss                  | [Events Store](/learn/events-store) |
| Replay historical messages                    | [Events Store](/learn/events-store) |
| One consumer per message, guaranteed delivery | [Queues](/learn/queues)             |
| Retry, DLQ, delayed delivery                  | [Queues](/learn/queues)             |
| Synchronous request-reply                     | [RPC](/learn/rpc)                   |
| Execute action, confirm success               | [RPC Commands](/learn/rpc)          |
| Request data, get result                      | [RPC Queries](/learn/rpc)           |

## Combining Patterns [#combining-patterns]

Patterns can work together in a single application. KubeMQ's channel routing syntax lets you publish to multiple patterns simultaneously. Here are two common shapes.

<Mermaid
  chart="graph LR
  API[&#x22;API Service&#x22;]
  RPC{{&#x22;RPC<br/>Process Order&#x22;}}
  ES{{&#x22;Events Store<br/>Order Log&#x22;}}
  Q{{&#x22;Queue<br/>Fulfillment&#x22;}}

  API -- command --> RPC
  RPC -- event --> ES
  ES -- queue --> Q

  class API client
  class RPC command
  class ES store
  class Q queue"
/>

*Order pipeline: a command processes the order, emits an event to the durable log, which feeds a queue for reliable fulfillment.*

<Mermaid
  chart="graph LR
  Write[&#x22;Write Service&#x22;]
  CMD{{&#x22;Commands<br/>Update&#x22;}}
  Store{{&#x22;Events Store<br/>Changes&#x22;}}
  Read[&#x22;Read Service<br/>Projection&#x22;]
  Client[&#x22;Client&#x22;]

  Write -- command --> CMD
  CMD -- event --> Store
  Store -- subscribe --> Read
  Client -- query --> Read

  class Write,Client,Read client
  class CMD command
  class Store store"
/>

*CQRS shape: commands write through the event store, the read service subscribes to build its projection, and clients query that read side.*

Channel routing syntax: use `;` to separate channels and `:` to prefix the pattern type:

```text
events:live-feed;events_store:archive;queues:process
```

## Get Started [#get-started]

<Cards>
  <Card title="Events" href="/learn/events/getting-started" description="Publish your first event in 5 minutes." />

  <Card title="Events Store" href="/learn/events-store/getting-started" description="Publish persistent events with replay." />

  <Card title="Queues" href="/learn/queues/getting-started" description="Send and receive your first queue message." />

  <Card title="RPC" href="/learn/rpc/getting-started" description="Send your first command and query." />
</Cards>