Instead of writing to an outbox table, a service publishes an OrderPlaced event to Kafka first, and a consumer inside that same service subscribes to its own topic to then update its local 'orders' read table. What is this approach called, and how does it avoid the dual-write problem?

## What the pattern is The 'listen to yourself' pattern is a second, structurally different way to achieve the same goal as the transactional outbox: atomically tying a state change to an event about that state change, without a distributed transaction across a database and a broker. - **Outbox** achieves atomicity by making the event durable in the same local transaction as the state (and delivering it out-of-band afterward). - **Listen-to-yourself** achieves it by removing the second write path entirely - there is only ever one authoritative action, publishing the event, and every effect of that action, including the originating service's own database update, is derived from consuming it back. ## The mechanism, step by step Concretely: when a client asks the order service to place an order, 1. the service does **not** call `db.save(order)` at all as part of handling that request; 2. instead, it publishes an `OrderPlaced` event to the broker as essentially the entire synchronous response to the request (the response to the client may be a 202 Accepted, or the service may wait for its own consumer to finish before responding); 3. separately, the same service runs a consumer subscribed to its own `OrderPlaced` topic, and it is that consumer handler - not the original request handler - that actually performs `db.save(order)`. Any other service (shipping, notifications) subscribes to the identical topic and does the analogous thing for its own concerns. From the broker's point of view, the originating service is just another consumer of its own event. ## Why this avoids dual writes Why does this avoid dual writes? Because dual-write risk specifically comes from two independent operations that can each fail on their own, leaving the system in a state where one happened and the other didn't. Listen-to-yourself has only one operation with independent failure risk - the publish - and the database write is not an independent action at all; it's a deterministic reaction to consuming a message that, once durably in the broker, will keep being redelivered until it's successfully processed. There's no window where 'the event went out but the DB never got updated,' because the DB update literally cannot happen except by consuming that event. ## The trade-offs The trade-offs are real and different in character from outbox's trade-offs. - **Latency and consistency shape.** First, with outbox, the primary request path is synchronous and consistent (the order is genuinely committed to the DB by the time the client gets a response; publishing merely trails behind asynchronously). With listen-to-yourself, even the originating service's own database write is now asynchronous - a client that calls place-order and then immediately calls get-order on the very same service is not guaranteed to see it, because the read model is only populated once the self-consumption completes. This **read-your-own-writes** gap on the originating service is often the deciding factor against this pattern for user-facing APIs with strict consistency expectations. - **No local transactional fallback.** Second, if the broker loses the message (misconfigured acks, an under-replicated partition losing its leader before replication completed) before this service's own consumer ever sees it, the state change never happens anywhere, including in the service's own database - the system's only source of truth was the broker, so the whole design leans entirely on the broker's durability guarantees, with no independent record to reconcile from. With outbox, by contrast, the outbox row's existence in a durable relational database is itself a fallback record, independent of the broker having received anything yet. ## Where it actually shows up Because of these trade-offs, listen-to-yourself is typically chosen as an alternative implementation strategy to outbox, not layered on top of it, and is comparatively less common in mainstream microservice practice than outbox specifically because most services do want a synchronous, consistent primary write path and can't tolerate their own reads lagging their own writes by a broker round-trip. It tends to show up in designs that are already fundamentally **event-sourced or CQRS-oriented**, where the write side is naturally 'append event, derive read model asynchronously' regardless of which service is doing the deriving - in those architectures the pattern isn't adding new asynchrony, it's just reusing the same event stream the design already treats as the source of truth.