One model doing two very different jobs eventually gets tired.

A single model for everything

Most applications begin with one database and one set of tables. The same tables are used to save data and to show data. This is simple and works well for a long time. But as the system grows, the two jobs start to pull in opposite directions.

• Writing wants safety. Data must be checked, kept consistent, and stored in a tidy shape without repetition.
• Reading wants speed. Screens and reports want data already combined, sorted, and shaped exactly as displayed, often with repetition to avoid slow joins.
• The volumes differ. In many systems reads are ten, a hundred, or a thousand times more frequent than writes.
• The teams differ. Business rules change one way, while screens and reports change another.

The pain points

Learn these words once, and the rest of the guide becomes easy.

The idea is small. The consequences are big.

The core idea

CQRS says: do not use the same model to change data and to read data. Create one path for commands and one path for queries. Each path can have its own code, its own data shape, its own database, and even its own servers.

The older idea behind it

CQRS grew from a simple rule about methods in programs: a method should either do something (a command) or answer something (a query), but never both. A method that returns a value should not also secretly change things. CQRS takes this rule and applies it to the whole system, not just to single methods.

flowchart LR
    U["User"] -->|"command: change something"| W["Write side"]
    U -->|"query: look at something"| R["Read side"]
    W --> WD[("Write store")]
    R --> RD[("Read store")]
    

In the picture, the user sends two kinds of requests. Commands go to the write side, which has its own store. Queries go to the read side, which has its own store. What is still missing is how the read store learns about changes made on the write side. That is where Kafka enters in the next chapters.

Once you split the system in two, you need a dependable road between the halves.

What Kafka gives you

Kafka is a system that stores messages in ordered logs, called topics, and lets many programs read them independently. Those features solve the exact problems CQRS creates.

The spine of the system

In a CQRS system built with Kafka, the topics carrying events form the spine. The write side puts facts on the spine. Every read side hangs off the spine and takes what it needs. If a read side breaks, the spine still holds every fact, and the read side can be repaired by reading the spine again.

A tour of all the moving parts, from a user’s click to a screen update.

flowchart LR
    C["Client"] -->|"command"| CH["Command handler"]
    CH --> WDB[("Write database")]
    CH -->|"publishes event"| K[["Kafka topic"]]
    K --> P1["Projection A"]
    K --> P2["Projection B"]
    P1 --> RDB1[("Read store A")]
    P2 --> RDB2[("Read store B")]
    C -->|"query"| QH["Query handler"]
    QH --> RDB1
    QH --> RDB2
    

Meet the components

Where the rules live and where decisions are made.

What a command looks like

A command names an intention: “Place order”, “Change delivery address”, “Cancel booking”. It carries the data needed, such as the customer, the items, and a unique identifier. It is written in the imperative, as an instruction, and it may be rejected.

What the handler does

1. Receive the command from the client.
2. Check that the caller is allowed and the data is valid.
3. Apply the business rules. For example, an order cannot be placed if stock is zero, and money cannot be withdrawn beyond the limit.
4. Save the result to the write database.
5. Publish one or more events to Kafka, saying what has happened.
6. Reply with success or a clear reason for refusal.

flowchart TB
    IN["Command arrives"] --> V{"Allowed and valid?"}
    V -->|"No"| REJ["Refuse with a reason"]
    V -->|"Yes"| RULE{"Business rules pass?"}
    RULE -->|"No"| REJ
    RULE -->|"Yes"| SAVE["Save to write database"]
    SAVE --> PUB["Publish event to Kafka"]
    PUB --> OK["Reply: accepted"]
    

Why the write model can be simple and strict

Because the write side no longer has to serve screens, it can be shaped purely around rules. It can use a tidy structure with no repetition, strong checks, and small transactions. It rarely needs to be fast at reading, so it does not need many indexes or complicated joins.

Where speed and convenience are the only goals.

Read models are built for the question

A read model is shaped for the way the answer will be shown. If a page needs “customer name, latest three orders, and total spent”, the read model stores exactly that, already combined. Answering the query becomes a single quick lookup, with no joining at question time.

Projections do the building

A projection is a program that reads events from Kafka and updates the read model. When it sees “order placed”, it adds the order to the customer’s list and raises the total. When it sees “order cancelled”, it removes the order and lowers the total. The projection is like a clerk who keeps the summary sheet up to date every time a new receipt arrives.

flowchart LR
    E1["Order placed"] --> PR["Projection"]
    E2["Order paid"] --> PR
    E3["Order cancelled"] --> PR
    PR --> V[("Customer summary view")]
    Q["Query: show customer summary"] --> V
    

Freedom of choice

Each read model can live in whatever store suits it best.

• A search screen may use a search engine.
• A profile page may use a fast key-value store.
• A monthly report may use an analytical database.
• A dashboard may use an in-memory cache.

This is sometimes called polyglot persistence, which simply means using several kinds of storage, each for what it does best.

These two ideas are often mentioned together, and often confused.

What event sourcing is

Normally a database stores the latest state: the account has 500 rupees. With event sourcing, the system stores every event that ever happened: deposited 1000, withdrew 300, withdrew 200. The current state is worked out by adding the events. The events are the true record; the state is just a summary.

How they relate

• CQRS without event sourcing is common. The write side keeps ordinary state in a normal database, and still publishes events so read models can be built.
• Event sourcing without CQRS is possible but awkward, since reading current state from raw events on every query is slow. Read models usually appear anyway.
• Both together is a natural pair: the event log is the write side’s truth, and projections build the read side.

The read side is always a little behind. Learn to live with it.

What it means

When a command succeeds, the write database is updated right away. But the read model is updated only after the event travels through Kafka and the projection processes it. In between, a query may return the old answer. Given a short time, the read model catches up. This is called eventual consistency.

How big is the gap?

In a healthy system, the gap is often tiny, from a few milliseconds to a few seconds. It grows when projections are slow, when Kafka consumers are lagging, or after an outage. You should measure it, watch it, and decide what is acceptable for each screen.

Follow a single request from the click to the updated screen.

sequenceDiagram
    participant U as User
    participant CH as Command handler
    participant DB as Write database
    participant K as Kafka
    participant P as Projection
    participant RS as Read store
    participant QH as Query handler
    U->>CH: Place order
    CH->>DB: Check rules and save
    CH->>K: Publish "order placed"
    CH-->>U: Accepted
    K->>P: Deliver event
    P->>RS: Update customer view
    U->>QH: Show my orders
    QH->>RS: Look up
    RS-->>QH: Ready answer
    QH-->>U: Orders list
    

Reading the diagram slowly

1. The user clicks “place order”. The command handler receives it.
2. The handler checks the rules against the write database and saves the order.
3. It publishes an “order placed” event to Kafka.
4. It answers the user: accepted. The user does not wait for the read side.
5. Kafka delivers the event to the projection, which updates the read store.
6. Later, the user asks to see their orders. The query handler looks in the read store and returns a ready answer.

Notice that the query never touches the write database, and the command never touches the read store. The only link between them is the event in Kafka.

The shape of your topics decides how easy everything else will be.

Commands as messages, or only events?

There are two common styles. In the first, commands travel over HTTP directly to the command handler, and only events are placed in Kafka. In the second, commands themselves are also put into a Kafka topic, and command handlers consume them. The second gives more buffering and lets the system absorb spikes, but it makes the reply to the user harder, since the user does not get an immediate answer. Many teams start with the first style for its simplicity.

One topic per kind of thing

A useful rule is to have one topic for each kind of business entity or “aggregate”, such as orders, customers, or payments. All events about orders go to the “orders” topic, so their order is preserved and consumers can follow the whole story of an order in one place.

What an event should carry

• A unique event id, so duplicates can be recognized.
• The entity id, so the event can be routed and ordered.
• The event type and a version number for the message format.
• A timestamp for when it happened.
• The facts, written in past tense: “order placed”, not “place order”.
• Enough data for consumers to act without calling back the write side.

Kafka keeps order only inside a partition, so choose the key carefully.

Why order matters

Suppose an order is placed, then paid, then cancelled. If a projection sees them as cancelled, placed, paid, it ends up with the wrong picture. Order matters, at least for events about the same thing.

How Kafka helps

Each message can have a key. Kafka uses the key to choose a partition: the same key always goes to the same partition. Inside a partition, messages are stored and read in the order they were written. If you use the order id as the key, all events for one order land in one partition, in the right order.

flowchart LR
    E1["Order 7: placed"] --> P0["Partition 0"]
    E2["Order 7: paid"] --> P0
    E3["Order 9: placed"] --> P1["Partition 1"]
    E4["Order 7: shipped"] --> P0
    E5["Order 9: cancelled"] --> P1
    

Choosing the key

• Use the id of the entity whose order you care about, such as the order id, account id, or customer id.
• Avoid keys that put most traffic on one value, since one partition will become overloaded, like a supermarket with one busy lane and many empty ones.
• Choose the partition count with future growth in mind. Adding partitions later changes which partition a key maps to, which can disturb ordering for existing data.

Several tools can turn events into read models. Each suits different needs.

flowchart LR
    T[["Orders topic"]] --> A["Plain consumer"]
    T --> B["Kafka Streams app"]
    T --> C["Connect sink"]
    A --> DB1[("Relational view")]
    B --> DB2[("Aggregated view")]
    C --> SE[("Search index")]
    

Kafka has a built-in way of thinking about “latest state per key”.

A stream and a table

In Kafka Streams, a stream is a never-ending sequence of events, and a table is the latest value for each key. If the events are “customer 5 moved to Pune” and later “customer 5 moved to Delhi”, the stream shows both, and the table shows only Delhi. A table is a natural read model: it always answers “what is the current state of this key?”.

Interactive queries

Kafka Streams can store that table in local state on the processing application, and let other programs ask it questions directly. This means an application can be both the projection and the query service, with no separate database. It is elegant for simple lookups, but it adds care around moving state when instances restart or scale.

A subtle trap sits between the write database and Kafka.

The trap

The command handler must do two things: save to the write database and publish an event to Kafka. These are two different systems. What if the save works, but the publish fails? The database says the order exists, but the read side never hears about it. What if the publish works and the save fails? The read side shows an order that does not exist. This is called the dual write problem.

The outbox solution

Instead of writing to two systems, the handler writes to one. In the same database transaction that saves the order, it also saves the event to a special table, the outbox. Either both are saved or neither. A separate process then reads new rows from the outbox and publishes them to Kafka. Some teams use a change-capture tool that watches the database log and sends new outbox rows to Kafka automatically.

flowchart LR
    CH["Command handler"] -->|"one transaction"| DB[("Write database")]
    DB --- OB["Orders table and outbox table"]
    OB --> RELAY["Relay or change capture"]
    RELAY --> K[["Kafka topic"]]
    

Messages can be delivered more than once. Projections must cope.

Why duplicates happen

• A consumer processes an event, then crashes before recording its progress. After restart, it reads the same event again.
• A producer retries after a timeout and the first attempt had in fact succeeded.
• The outbox relay sends a row twice after a restart.

The remedy: idempotent projections

An operation is idempotent if doing it twice gives the same result as doing it once. Projections can be made idempotent in several ways.

• Set values, do not add to them. “Set the order status to paid” is safe to repeat. “Add one to the paid count” is not.
• Remember processed event ids. Keep a small record of ids already handled, and skip repeats.
• Use version numbers. Apply an event only if its version is newer than what the view already holds.

What about “exactly once”?

Kafka offers features that can make reading, processing, and writing back into Kafka behave as if each message were handled exactly once, within Kafka’s own world. But once you write to an outside database, the guarantee is only as good as the database write. In practice, the safest habit is at-least-once delivery plus idempotent processing.

One of the greatest gifts of putting Kafka in the middle.

Why replay is powerful

Read models are disposable. If one is damaged, or if you invent a new view, you can throw the old one away and rebuild it by reading the topic again from the beginning. A new team can create a brand new view of last year’s data without asking anybody to export anything.

The limits of replay

• Retention. Replay works only as far back as Kafka keeps data. For full rebuilds, use long or unlimited retention on the event topics, or compaction where only the latest event per key matters.
• Time. Replaying billions of events takes a while. Plan for it, and consider snapshots.
• Side effects. A projection that also sends emails would send them all again. Keep projections free from side effects, or guard them.

Events are kept for years, so their format must be able to grow without breaking readers.

The challenge

Today’s “order placed” event has five fields. Next year, the business wants a sixth. Old events in the topic have five, new ones have six. Every consumer, old and new, must be able to read both.

Habits that help

• Use a schema. Describe each event’s shape formally, and store schemas in a schema registry so producers and consumers agree.
• Add, do not remove. New fields are usually safe if they are optional or have defaults. Removing or renaming fields breaks readers.
• Set compatibility rules. The registry can refuse a new schema version that would break existing consumers.
• Version big changes. If a change is truly incompatible, create a new event type or topic and migrate slowly.
• Be liberal in what you read. Projections should ignore fields they do not know.

The most visible symptom of eventual consistency, and how to soften it.

The situation

A user adds an item to their list and is sent straight to the list page. The page is served from the read model, which has not yet received the event. The item is missing. The user thinks the save failed, and clicks again, creating a duplicate.

Ways to handle it

sequenceDiagram
    participant U as User screen
    participant W as Write side
    participant R as Read side
    U->>W: Add item
    W-->>U: Accepted, version 42
    U->>R: Show list, wait for version 42
    Note over R: Projection catches up
    R-->>U: List including new item
    

The quiet superpower of CQRS with Kafka.

Because Kafka lets many consumer groups read the same topic independently, you can attach as many read models as you like. Each one is shaped for one audience, and none affects the others. Adding a new view means adding a new consumer group, and never changing the write side.

flowchart LR
    W["Write side"] --> T[["Events topic"]]
    T --> V1["Customer profile view"]
    T --> V2["Search index"]
    T --> V3["Analytics warehouse"]
    T --> V4["Notification service"]
    T --> V5["Fraud checks"]
    

What happens when one business action needs several services to agree.

The situation

Placing an order might need the stock service to reserve items, the payment service to charge the card, and the shipping service to book a courier. No single database transaction can cover all three services. If payment fails after stock was reserved, the reserved stock must be released.

The saga

A saga is a sequence of steps, where each step is a local action followed by an event, and where each step has a matching compensation, an action that undoes it if a later step fails. Kafka carries the events between the steps.

flowchart LR
    O["Order placed"] --> S["Stock reserved"]
    S --> P["Payment taken"]
    P --> H["Shipment booked"]
    P -->|"payment fails"| C["Release stock"]
    C --> X["Order cancelled"]
    

Two styles

• Choreography. Each service listens for events and reacts. There is no central boss. It is simple for small flows, but the whole story becomes hard to see when there are many services.
• Orchestration. A central coordinator, sometimes called a process manager, tells each service what to do and listens for the results. It is easier to follow and change, at the price of one more component.

The pattern is powerful, and power has a cost. Choose it with open eyes.

flowchart TB
    S["Considering CQRS"] --> Q1{"Are reads and writes very different in shape or volume?"}
    Q1 -->|"No"| N1["A single model is probably enough"]
    Q1 -->|"Yes"| Q2{"Can users accept a short delay?"}
    Q2 -->|"No"| N2["Use CQRS only where safe, read from write side elsewhere"]
    Q2 -->|"Yes"| Q3{"Can your team run Kafka and projections?"}
    Q3 -->|"No"| N3["Start smaller or use a managed service"]
    Q3 -->|"Yes"| Y["CQRS with Kafka is a good fit"]
    

A fair balance sheet.

The main trade-offs

• Consistency versus speed. You give up instant agreement between the sides to get fast, scalable reads.
• Simplicity versus flexibility. One model is easy to understand. Two models offer freedom, but ask for more discipline.
• Storage versus speed. Read models repeat data on purpose, using extra storage to save time at question time.
• Team independence versus coordination. Teams can build their own views, yet must agree on event contracts.

More places hold the data, so more places need guarding.

Guard the commands

Commands change things, so they need strong authentication, proving who the caller is, and authorization, checking whether that caller may do this action. The command handler is the right place to enforce both, before any rule is applied.

Guard the topics

• Encrypt the traffic between applications and Kafka.
• Use access rules so only the command side may write to event topics, and each projection may read only the topics it needs.
• Give every application its own identity, so you can tell who did what.

Guard the read models

Every read store holds a copy of some data. Apply the same care to each: who may query, which fields may be shown, and how long data may be kept. A screen for support staff may hide card numbers that the accounting view needs.

Sensitive data in events

Events stay in Kafka for a long time, maybe forever. Personal data placed in an event may be difficult to remove later. Options include keeping personal details out of events and storing only an id, encrypting sensitive fields, or planning a way to erase them, in line with the privacy laws that apply to you.

Because the system is spread out, you need to see across it.

Tracing across the gap

When a user says “my change did not show up”, you must follow it from the command, through the outbox and Kafka, to the projection and the read store. Give each command a correlation id that is copied into every event and every log line. Searching for that one id then shows the whole journey.

flowchart LR
    CMD["Command, id abc-123"] --> EVT["Event, id abc-123"]
    EVT --> PRJ["Projection log, id abc-123"]
    PRJ --> RDM["Read store update, id abc-123"]
    

Scale each side according to its own load.

Scaling the write side

The write side scales by adding command handler instances and, where needed, by spreading the write database. Partitioning by entity keeps related work together and avoids conflicts.

Scaling the read side

Reads are usually the bigger load. You can add more query handler instances, add replicas to the read store, add caches, or create extra read models tuned to heavy screens. None of this touches the write side.

Scaling the bridge

Kafka scales by partitions. More partitions allow more consumers in a group to work in parallel. But a consumer group can never have more active members than partitions, so choose enough partitions for your future peak.

Things will go wrong. Decide beforehand what should happen.

When a projection cannot process an event

Some events are bad: malformed, or referring to something unknown. If a projection keeps failing on the same event, it blocks the partition, and everything behind it waits. Common choices are:

• Retry a few times with pauses, in case the trouble is temporary.
• Move the bad event to a dead letter topic so processing continues, and inspect it later.
• Stop and alert for events that must never be skipped, because skipping would make the view wrong.

When Kafka is unavailable

With an outbox, the command side keeps working: events pile up in the outbox and are published when Kafka returns. Queries keep working too, since the read stores are separate, though they get gradually staler.

When a read store is lost

Rebuild it by replaying the topic. This is the reason to keep event topics long enough.

flowchart TB
    EV["Event arrives"] --> TRY{"Processed OK?"}
    TRY -->|"Yes"| DONE["Commit progress"]
    TRY -->|"No"| RETRY{"Retries left?"}
    RETRY -->|"Yes"| WAIT["Wait and try again"]
    WAIT --> TRY
    RETRY -->|"No"| DLQ["Send to dead letter topic and alert"]
    DLQ --> DONE
    

Splitting the system also splits the way you test it.

A few habits keep day-to-day life calm.

• Deploy sides independently. The great benefit of the split is that you can release a new projection without touching the command side.
• Deploy new consumers before new producers. When a new event type is introduced, make sure readers can handle it first.
• Use a new consumer group for a changed projection, let it catch up in parallel, then switch queries to it.
• Keep infrastructure as code, including topics, partitions, retention, and access rules.
• Plan capacity for catch-up. After an outage, projections work harder than normal to reach the present.
• Document event contracts in one place that every team can read.

flowchart LR
    OLD["Old projection, live"] --> Q["Queries"]
    NEW["New projection, catching up"] -.-> Q
    NEW -->|"caught up: switch"| Q
    OLD -->|"then retire"| END["Retired"]
    

Few teams start from an empty page. Most move step by step.

A short tour of the settings and abilities you will lean on.

Compaction versus long retention

Two strategies exist for keeping enough history to rebuild read models. With long retention, every event is kept for a long period, or forever, so the full story can be replayed. With compaction, Kafka keeps only the latest message per key, which is enough for views that care about current state, but loses the history between. Choose long retention for event streams that tell stories, and compaction for topics that carry “latest state” records.

Reusable ideas that keep a CQRS system healthy.

Mistakes that turn a neat idea into a messy system.

A checklist gathered from many projects.

A made-up example, told in plain steps.

flowchart LR
    CU["Customer"] -->|"place order"| OS["Order service"]
    OS --> ODB[("Orders database")]
    OS --> OBX["Outbox"]
    OBX --> KT[["Orders topic"]]
    KT --> H["History projection"]
    KT --> S["Search projection"]
    KT --> A["Analytics projection"]
    H --> HS[("Document store")]
    S --> SI[("Search index")]
    A --> WH[("Warehouse")]
    CU -->|"view history"| HS
    CU -->|"search products"| SI
    

The result: checkout is no longer disturbed by reports, product pages are fast, and new views can be added by attaching another consumer. The cost: the team now watches lag, manages event formats, and designs screens with eventual consistency in mind. It is a fair trade for a shop of this size, and a poor trade for a tiny one.

Ideas that lead teams into trouble.

Generic pictures of how different kinds of businesses use these ideas, without naming particular companies.

A small idea that explains how the write side stays correct.

What an aggregate is

An aggregate is a group of related things that must always be consistent together, treated as one unit. An order and its order lines form one aggregate: the total must always match the lines. A command changes one aggregate at a time, and the aggregate checks its own rules before agreeing.

Why it matters for Kafka

• The aggregate id is the natural message key. Events of one aggregate land in one partition, in order.
• One command, one aggregate. Changing two aggregates in one transaction couples them. Use events and sagas to coordinate instead.
• Small aggregates scale better. Big ones cause many commands to compete for the same data.

flowchart LR
    CMD["Command: add item to order 7"] --> AG["Order 7 aggregate"]
    AG --> CHK{"Rules pass?"}
    CHK -->|"Yes"| EV["Event: item added to order 7"]
    CHK -->|"No"| ER["Refuse"]
    EV --> KP["Partition chosen by key: order 7"]
    

Handling two commands at once

What if two commands try to change the same aggregate at the same moment? A common answer is optimistic concurrency: each aggregate carries a version number. A command says “I am changing version 5”. If the aggregate is already at version 6, the command is refused and can be retried with fresh data. This avoids locking and keeps writes fast.

You do not have to jump to the biggest version. There is a ladder.

Turn “eventually” into something concrete.

Write down a freshness target

For every read model, agree on a number: “This view is normally less than two seconds behind, and never more than thirty.” That statement can be measured, alerted on, and understood by product owners. Without it, “eventual” can mean anything.

Different screens, different needs

flowchart TB
    Q["How fresh must this screen be?"] --> N{"Must be exact right now?"}
    N -->|"Yes"| W["Read from the write side, or use the command reply"]
    N -->|"A few seconds is fine"| V["Read model plus version wait"]
    N -->|"Minutes or hours are fine"| B["Ordinary read model or warehouse"]
    

In larger companies, the two sides may belong to different teams.

Each service owns its writes

In a system of many small services, each service is the only writer of its own data. The orders service alone changes orders. The customers service alone changes customers. Other services that need this data do not reach into its database. Instead they listen to its events on Kafka and keep their own read models.

flowchart LR
    OS["Orders service"] -->|"order events"| K[["Kafka"]]
    CS["Customers service"] -->|"customer events"| K
    K --> SH["Shipping service: own view of orders and customers"]
    K --> BI["Billing service: own view of orders and customers"]
    K --> RC["Recommendations: own view of orders"]
    

Why this is good

• No shared database. Each team can change its storage freely.
• Less live coupling. A service can work even when another is down, using its last known view.
• Clear ownership. Only the owner may write; everybody else may only read.

What to watch

• Copies of data can drift. Monitor lag in every consuming service.
• Event formats become contracts between teams, so agree who owns them and how they change.
• Do not build a maze where every service depends on everyone’s events. Keep the picture readable.

Technology choices are also choices about people and money.

The running cost

• Infrastructure: Kafka brokers, extra databases for read models, and the machines running projections.
• Storage: Read models repeat data on purpose, and event topics may be retained for a long time.
• Operations: Someone must watch lag, handle failed events, and manage upgrades.

The skills needed

Teams need to understand messaging, ordering, idempotency, and schema evolution. These are learnable, but they take time, and mistakes in the first months are normal. Plan for learning, and start with a small, low-risk area.

Ways to lower the burden

• Use a managed Kafka service, so brokers are someone else’s daily concern.
• Use Kafka Connect for simple copies, rather than writing custom code.
• Provide shared libraries, templates, and standards for events, so each team does not start from zero.
• Write a short guide of “how we do CQRS here” and keep it alive.

When something looks wrong, start from what you can see.

flowchart TB
    P["User reports missing change"] --> A{"Did the command succeed?"}
    A -->|"No"| A1["Look at command handler logs and rule failures"]
    A -->|"Yes"| B{"Is the event in Kafka?"}
    B -->|"No"| B1["Check the outbox and relay"]
    B -->|"Yes"| C{"Has the projection consumed it?"}
    C -->|"No"| C1["Check consumer lag and errors"]
    C -->|"Yes"| D["Check the read store and the query handler"]
    

Confirm these before real users depend on the system.

Everything in one place.

CQRS splits a system into a side that changes data and a side that reads data, because these two jobs have different needs. Kafka is the natural bridge: the write side publishes events, and any number of read-side projections consume them to build views shaped for their screens. The gains are independent scaling, fast queries, freedom of storage, and the power to replay. The costs are eventual consistency, more parts to run, and discipline about events. Careful keys, an outbox, idempotent projections, schemas, monitoring of lag, and a gradual adoption plan keep the costs under control.