# Messaging Patterns (/docs/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="/docs/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="/docs/learn/events" description="How KubeMQ implements those concepts: Events, Events Store, Queues, and RPC." />

  <Card title="3 · Choosing & Combining" href="/docs/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](/docs/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="/docs/learn/events" description="Fire-and-forget pub/sub with at-most-once delivery. Fastest pattern, no persistence." />

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

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

  <Card title="RPC (Commands & Queries)" href="/docs/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](/docs/learn/events) | [Events Store](/docs/learn/events-store) | [Queues](/docs/learn/queues) | [RPC](/docs/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](/docs/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](/docs/learn/events)             |
| Pub/sub with no message loss                  | [Events Store](/docs/learn/events-store) |
| Replay historical messages                    | [Events Store](/docs/learn/events-store) |
| One consumer per message, guaranteed delivery | [Queues](/docs/learn/queues)             |
| Retry, DLQ, delayed delivery                  | [Queues](/docs/learn/queues)             |
| Synchronous request-reply                     | [RPC](/docs/learn/rpc)                   |
| Execute action, confirm success               | [RPC Commands](/docs/learn/rpc)          |
| Request data, get result                      | [RPC Queries](/docs/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="/docs/learn/events/getting-started" description="Publish your first event in 5 minutes." />

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

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

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