مدیریتِ داده: Database-per-Service، Saga، Outbox و CQRSData Management: DB-per-Service, Saga, Outbox, CQRS

By now you've learned how to split services apart, make them talk, and keep them resilient. Now we reach the hardest, most unforgiving part of microservices: data. Pretty stateless code splits easily; but the moment two services must agree on a business fact ("the order was placed, stock was decremented, money was charged"), the full weight of distributed systems lands on your shoulders.

In a monolith this agreement was almost free: one @Transactional, one database, one atomic commit. Either everything happened or nothing did. In microservices that magic disappears, because you no longer have one database and one transaction. This chapter is about how, when you lose that magic, you rebuild a trustworthy system with the right tools (Saga, Outbox, CDC, CQRS) — instead of pretending the problem isn't there.

1) Each Service, Its Own Database — Database per Service

The Database per Service principle sounds simple but runs deep: each microservice has its own private database, and no other service is allowed to touch those tables directly. The only way to reach a service's data is through its API or its events. A service's tables are its internal details — exactly like private fields in a class.

"Private database" doesn't necessarily mean a separate physical installation. There are three isolation levels, each with its place:

Here's the shape of a healthy system. Database-per-Service topology | Each service owns a private database:

flowchart LR
  Client --> Gateway
  Gateway --> OrderSvc[Order Service]
  Gateway --> InventorySvc[Inventory Service]
  Gateway --> PaymentSvc[Payment Service]
  OrderSvc --> OrderDB[(Order DB)]
  InventorySvc --> InvDB[(Inventory DB)]
  PaymentSvc --> PayDB[(Payment DB)]
  OrderSvc -. events .-> Broker[(Kafka)]
  InventorySvc -. events .-> Broker
  PaymentSvc -. events .-> Broker

Why does this matter so much?

1. Team and deployment independence. If the Order team wants to add a column or migrate from Postgres to a document store, they shouldn't have to coordinate with any other team. A shared schema means every schema change must be negotiated across all teams — exactly the coupling microservices were supposed to remove.

2. Freedom to pick technology (Polyglot Persistence). The catalog service might want Elasticsearch, the cart Redis, accounting a strict ACID Postgres, and the social graph Neo4j. Each service picks the right tool for its job.

3. Fault and performance isolation. A heavy query or full-table lock in one service doesn't freeze the others. The blast radius stays contained.

4. Independent scalability. You can shard or add replicas to a read-heavy hot service without bloating anyone else's database.

2) The Shared-Database Anti-Pattern — the silent killer

Many teams migrate to microservices, split the services apart, but keep everyone connected to one shared database. On paper they have microservices; in practice they've built a distributed monolith with the drawbacks of both worlds.

Why is it so bad? Suppose Order and Reporting both query the orders table directly.

Exception: in a modular monolith (e.g. with Spring Modulith 2.1), one database with logically separate schemas is perfectly fine, because you still have one deployment and one transaction. Shared Database is only an anti-pattern when services deploy and scale independently but smuggle a shared database underneath.

3) Why We Abandon Distributed Transactions and 2PC

OK, now every service owns its database. But a business operation often touches several services: "place order" means reserve stock + charge money + create an order record. If each has a separate database, how do they all commit or roll back together?

The classic database-world answer is Two-Phase Commit (2PC) over the XA protocol: a coordinator tells everyone to "prepare," they all take locks and say "ready," then the coordinator says "commit." On paper it's atomic. In microservices, it's almost always wrong.

So what's the solution? Instead of striving for distributed atomicity, we break atomicity into a sequence of local transactions (each atomic in its own database) and accept that the system is briefly inconsistent before it converges. That idea is called Eventual Consistency, and its execution tool is the Saga.

4) Eventual Consistency

Eventual Consistency means: if no new writes arrive, all replicas and services eventually converge on the same value. Between the write and the convergence there's an inconsistency window — usually milliseconds to a few seconds.

Accepting that window is a product decision, not just a technical one. You must talk to the business: "Is it a problem if a buyer sees their order in 'My Orders' two seconds after placing it?" The answer is almost always "no, that's fine" — and that single decision opens the door to scalable architecture.

5) Saga — a distributed transaction without distributed locks

A Saga is a sequence of local transactions. Each step commits in its own service's database and emits an event that triggers the next step. If a step fails, the Saga undoes prior steps with compensating transactions.

The compensating transaction — the hard rule

Every step must have an idempotent and effectively always-succeeds compensation. If the "reserve" step's compensation is "release," release must work without error even if the reservation was half-done or already released. A compensation that itself fails means the system is stuck in an inconsistent state forever.

Two Saga styles: choreography and orchestration

Choreography: there is no central brain. Each service listens to others' events, reacts, and emits its own. Like a dance troupe with no leader, where each dancer sees their neighbor's move and makes the next.

Orchestration: a central coordinator (Saga Orchestrator) sends explicit commands to each service, waits for replies, and decides the next step. Like an orchestra with a conductor.

Here's the full flow in both styles. Choreography saga for order placement | event-driven, no central brain:

sequenceDiagram
  participant O as Order Service
  participant K as Kafka
  participant I as Inventory Service
  participant P as Payment Service
  O->>K: OrderCreated (status=PENDING)
  K->>I: OrderCreated
  I->>I: reserve stock (local tx)
  I->>K: StockReserved
  K->>P: StockReserved
  P->>P: charge card (local tx)
  P->>K: PaymentCompleted
  K->>O: PaymentCompleted
  O->>O: status=CONFIRMED (local tx)
  Note over P,O: if charge fails -> PaymentFailed -> Inventory releases stock (compensation)

Now the same with a central brain. Orchestration saga driven by a coordinator | one state machine decides each step:

sequenceDiagram
  participant SO as Order Saga Orchestrator
  participant I as Inventory Service
  participant P as Payment Service
  SO->>I: ReserveStock (command)
  I-->>SO: StockReserved (reply)
  SO->>P: ChargePayment (command)
  P-->>SO: PaymentFailed (reply)
  SO->>I: ReleaseStock (compensation command)
  I-->>SO: StockReleased
  Note over SO: Orchestrator holds the state machine and decides each next step

Comparison: which style should I pick?

A minimal hand-rolled orchestrator with a state machine (conceptual, Spring):

public enum OrderSagaState {
    STARTED, STOCK_RESERVED, PAYMENT_DONE, COMPLETED, COMPENSATING, FAILED
}

@Component
public class OrderSagaOrchestrator {

    private final CommandGateway commands;   // sends messages to services
    private final SagaStateRepository repo;   // saga_state table in the Order DB

    // called on each incoming reply (e.g. from a Kafka listener)
    @Transactional
    public void on(SagaReply reply) {
        SagaInstance saga = repo.findById(reply.sagaId()).orElseThrow();

        switch (saga.getState()) {
            case STARTED -> {
                if (reply instanceof StockReserved) {
                    saga.setState(OrderSagaState.STOCK_RESERVED);
                    commands.send(new ChargePayment(saga.getOrderId(), saga.getAmount()));
                } else { // StockRejected
                    saga.setState(OrderSagaState.FAILED);
                    // nothing reserved, no compensation needed
                }
            }
            case STOCK_RESERVED -> {
                if (reply instanceof PaymentCompleted) {
                    saga.setState(OrderSagaState.COMPLETED);
                } else { // PaymentFailed -> compensate
                    saga.setState(OrderSagaState.COMPENSATING);
                    commands.send(new ReleaseStock(saga.getOrderId())); // compensating action
                }
            }
            case COMPENSATING -> saga.setState(OrderSagaState.FAILED); // StockReleased arrived
            default -> { /* idempotent: ignore a duplicate reply */ }
        }
        repo.save(saga); // saving saga state AND sending a message must be atomic -> Outbox!
    }
}

That last comment leaks the most important point: when you save the saga and send a message at the same time, you hit exactly the problem the whole Saga was meant to solve. It's called Dual-Write.

6) The Dual-Write Problem and Its Cure: the Outbox Pattern

Every Saga step does two things at once: (1) it changes the local database, and (2) it publishes an event/message. But these are two different systems (the DB and Kafka) that don't share a transaction. This "writing to two sources" is the Dual-Write Problem.

@Transactional
public void placeOrder(Order order) {
    orderRepository.save(order);            // (1) commit to the DB
    kafkaTemplate.send("orders", event);    // (2) publish to Kafka
}

The solution: Transactional Outbox

The idea is brilliant and simple: instead of writing to two systems, write to one. Create an outbox table in the service's own database. In the same local transaction that writes the business data, insert the event as a row in the outbox table. Because both are in one DB transaction, either both commit or neither does — atomic, guaranteed.

Then a separate process (relay) reads the outbox rows and sends them to Kafka, marking them done.

The Outbox pattern flow with CDC | Transactional Outbox with change data capture:

flowchart LR
  App[Order Service] -->|single local tx| DB[(Order DB)]
  DB --- OB[outbox table]
  CDC[Debezium Connector] -->|reads WAL/redo log| OB
  CDC -->|publishes| Kafka[(Kafka)]
  Kafka --> Consumers[Inventory / Payment]

Here's the outbox table DDL in both dialects. The structure is deliberately aligned with Debezium's expectations (id, aggregatetype, aggregateid, type, payload):

-- PostgreSQL
CREATE TABLE outbox (
    id            UUID         PRIMARY KEY DEFAULT gen_random_uuid(),
    aggregatetype VARCHAR(255) NOT NULL,   -- e.g. "Order" -> maps to topic name
    aggregateid   VARCHAR(255) NOT NULL,   -- e.g. orderId -> message key (partitioning)
    type          VARCHAR(255) NOT NULL,   -- e.g. "OrderCreated"
    payload       JSONB        NOT NULL,   -- the event body
    created_at    TIMESTAMPTZ  NOT NULL DEFAULT now()
);

-- Oracle (19c/23ai)
CREATE TABLE outbox (
    id            RAW(16)        DEFAULT SYS_GUID() PRIMARY KEY,
    aggregatetype VARCHAR2(255)  NOT NULL,
    aggregateid   VARCHAR2(255)  NOT NULL,
    type          VARCHAR2(255)  NOT NULL,
    payload       CLOB           NOT NULL,   -- or JSON in 23ai
    created_at    TIMESTAMP WITH TIME ZONE DEFAULT SYSTIMESTAMP NOT NULL
);

The service code now deals with just one local transaction — no Kafka, no dual-write:

@Service
public class OrderService {

    private final OrderRepository orders;
    private final OutboxRepository outbox;
    private final ObjectMapper json;

    @Transactional   // one atomic local tx: both inserts commit together
    public void placeOrder(PlaceOrderCommand cmd) {
        Order order = Order.pending(cmd);
        orders.save(order);

        OutboxEvent event = new OutboxEvent(
            "Order",                       // aggregatetype -> topic
            order.getId().toString(),      // aggregateid  -> message key
            "OrderCreated",                // type
            json.writeValueAsString(new OrderCreated(order))  // payload
        );
        outbox.save(event);   // just one more write in the same DB; no Kafka
    }   // COMMIT: either both rows, or neither
}

Two ways to publish the outbox: Polling vs CDC

Polling Publisher: a short-interval job runs SELECT ... FROM outbox WHERE processed = false ORDER BY created_at, sends each row to Kafka, and marks processed=true (or DELETEs the row). Simple, no extra infrastructure, but it has latency (tied to the poll interval), puts a constant query load on the DB, and you must handle ordering and concurrency (multiple instances) by hand (SELECT ... FOR UPDATE SKIP LOCKED).

Change Data Capture (CDC): instead of polling, a tool like Debezium reads the database transaction log directly (WAL in Postgres, redo/LogMiner or OpenLogReplicator in Oracle, binlog in MySQL) and streams every INSERT into the outbox table to Kafka in real time. It adds no query load on the DB, has low latency, and preserves ordering from the log itself.

Debezium + Outbox Event Router

Debezium ships a ready transform called the Outbox Event Router (a Single Message Transform) built precisely for this pattern: it takes the raw CDC row from the outbox table and reshapes it into a clean message on the right topic. By default aggregatetype determines the destination topic (outbox.event.${aggregatetype}), aggregateid becomes the message key (so an aggregate's events stay in one partition and in order), and payload is the message body.

Debezium connector config for Postgres with the outbox router (Debezium 3.6, on Kafka Connect):

{
  "name": "order-outbox-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "order-db",
    "database.port": "5432",
    "database.user": "debezium",
    "database.password": "${secret:pg-pass}",
    "database.dbname": "orders",
    "topic.prefix": "orderdb",
    "table.include.list": "public.outbox",
    "plugin.name": "pgoutput",

    "transforms": "outbox",
    "transforms.outbox.type": "io.debezium.transforms.outbox.EventRouter",
    "transforms.outbox.route.by.field": "aggregatetype",
    "transforms.outbox.table.field.event.key": "aggregateid",
    "transforms.outbox.table.field.event.payload": "payload",
    "transforms.outbox.route.topic.replacement": "outbox.event.${routedByValue}"
  }
}

An idempotent consumer on the Inventory side:

@KafkaListener(topics = "outbox.event.Order")
@Transactional
public void on(ConsumerRecord<String, String> rec) {
    String eventId = header(rec, "id");     // unique event id from the header
    if (processedEvents.existsById(eventId)) {
        return;   // seen it; ignore (idempotency)
    }
    OrderCreated evt = json.readValue(rec.value(), OrderCreated.class);
    inventory.reserve(evt.orderId(), evt.items());   // business logic
    processedEvents.save(new ProcessedEvent(eventId)); // record "seen" in the same tx
}

7) CQRS — separating reads from writes

We've solved writing. But what about reading? Suppose the "My Orders" page must show the product name and image (from Catalog), the address (from User), and shipping status (from Shipping) side by side. With Database-per-Service you can no longer JOIN across these — the tables live in different databases. This is the "cross-service query problem."

CQRS (Command Query Responsibility Segregation) means handing the write (Command) and read (Query) responsibilities to two separate models. The write model is normalized and correct; the read model (Read Model / Materialized View) is pre-joined and denormalized so a page query is answered in one simple read.

How does that read model get populated? By the same events that flow out of the Outbox/Kafka. A read service (or a module inside the Order service) listens to OrderCreated, OrderShipped, ProductRenamed, ... and builds and maintains a flat, display-ready table.

CQRS architecture with an event-driven read model | separate write and read models:

flowchart LR
  Cmd[Command API] -->|writes| WriteDB[(Write Model - normalized)]
  WriteDB -->|outbox/CDC events| Kafka[(Kafka)]
  Kafka --> Projector[Projector]
  Projector -->|denormalized upsert| ReadDB[(Read Model - query-optimized)]
  Query[Query API] -->|fast reads| ReadDB

The projector that builds the read model:

@Component
public class OrderSummaryProjector {

    private final OrderSummaryRepository readModel;

    @KafkaListener(topics = {"outbox.event.Order", "outbox.event.Shipping"})
    @Transactional
    public void on(DomainEvent evt) {
        switch (evt) {
            case OrderCreated e -> readModel.upsert(new OrderSummary(
                    e.orderId(), e.userId(), e.total(), "PENDING", e.createdAt()));
            case OrderShipped e -> readModel.updateStatus(e.orderId(), "SHIPPED");
            case ProductRenamed e ->                       // denormalized name
                    readModel.renameProductEverywhere(e.productId(), e.newName());
            default -> { /* ignore */ }
        }
    }
}

The read-model upsert query is also dialect-specific:

-- PostgreSQL: native upsert
INSERT INTO order_summary (order_id, user_id, total, status, created_at)
VALUES (:orderId, :userId, :total, 'PENDING', :createdAt)
ON CONFLICT (order_id)
DO UPDATE SET total = EXCLUDED.total, status = EXCLUDED.status;

-- Oracle: MERGE
MERGE INTO order_summary t
USING (SELECT :orderId AS order_id FROM dual) s
   ON (t.order_id = s.order_id)
WHEN MATCHED THEN
   UPDATE SET t.total = :total, t.status = :status
WHEN NOT MATCHED THEN
   INSERT (order_id, user_id, total, status, created_at)
   VALUES (:orderId, :userId, :total, 'PENDING', :createdAt);

8) Event Sourcing — one step further

CQRS often travels with a more radical idea: Event Sourcing.

In Event Sourcing, instead of storing the entity's current state, you store the sequence of changes (events). Current state is computed by "replaying" all events from the beginning. You have no orders table with a status column; instead you have an event store with: OrderCreated, ItemAdded, OrderPaid, OrderShipped.

Benefits: complete, free audit (the entire history is inherently there), time travel (state at any instant), and a natural source for CQRS and integration (the events themselves are the source of truth, so no dual-write).

9) Designing for Eventual Consistency and Data Ownership

Now that you have the tools, here are the design principles a senior follows:

Summary comparison of the patterns:

Interview Questions