Event-Driven Design

In request-driven, one service asks another and waits for an answer right away, like a phone call. In event-driven, a service announces "this happened" and moves on, and other services react whenever they get around to it, like a text message.

It's called event notification: a thin 'something happened' alert with no data, so listeners must ask for details afterward. The other style, event-carried state transfer, puts all the needed details inside the message itself.

If the app writes to the database and then sends a message as two separate steps, one can succeed while the other fails - the app crashing between them means the database and other services disagree about what happened.

Choreography removes direct service-to-service calls, but every subscriber still depends on the exact shape of the events it listens to. That's still coupling - to a shared event contract instead of an API - and it's invisible because nobody 'calls' anywhere, so nobody tracks who depends on what.

If you call directly, you know right away it worked, but you depend on that service being up. If you publish an event, you don't depend on it being up right now, but you don't know immediately whether it processed the change, and it might be out of sync for a bit.

Thin events keep the producer as the single source of truth so data is always current, but every consumer has to call back, tying them to the producer being online. Fat events remove that call-back dependency but consumers can end up working with slightly outdated data.

The service writes both the order row and a row describing the event into the same database transaction. A separate background process then reads the new outbox rows, sends them to the message broker, and marks them as sent - so the event is only ever 'in flight' if the original database write actually succeeded.

Nobody owns the whole flow, so there's no single place that knows 'step 4 never happened.' You have to reconstruct the story by piecing together logs from every service using a shared trace ID, and build dashboards specifically for tracking process state across services.

In a normal call chain, you can follow one thread step by step in the logs. In an event system, many independent services react on their own schedule, so there's no single thread to follow, and you need extra tools like tracking IDs and dashboards to piece the story back together.

Pick the style per consumer based on how much data they need, how current it must be, and how many consumers are asking - big or many-and-varied needs favor a fat event, few-and-current needs favor callbacks. Event sourcing is a different, bigger decision: making events the actual system of record, not just a way to tell other services something happened.

The outbox pattern guarantees an event eventually gets published if the database write succeeded, but not that it's published exactly once or perfectly ordered across everything - so consumers must be built to safely handle duplicate or occasionally reordered messages.

The orchestrator now has to know about and call every participant directly, so all the workflow logic and every change request funnels through one service. That service becomes a single point of failure and a bottleneck for both scaling and code changes.

The inventory count hasn't caught up yet because the update happens a little after the purchase, not instantly. You can shrink that gap or accept it as normal, but some delay is expected with this design.

If an older update arrives after a newer one, the analytics copy can be overwritten with stale data. Adding a version number or timestamp to each event and only applying it if it's newer fixes this.

Polling repeatedly asks the database 'anything new?' which adds load and delay. CDC tools like Debezium instead tap directly into the database's internal change log and stream new rows out in near real time, without hammering the table with queries - but it needs more setup and access to that low-level log.

When you can no longer hold the whole flow's logic in your head just from the events - lots of branches, retries, timeouts, ordering rules - that's the signal. Move that control-flow logic into a central orchestrator so the branching lives in one place instead of scattered across many services' event handlers.

If the call is direct and synchronous, the upstream service can get stuck or start failing too while the other service is down. If it's an event, the upstream service is fine — the messages just pile up and get processed once the other service comes back.

Add version numbers so consumers can tell old data from new, periodically resend full snapshots so gaps self-heal, and evolve the event schema by adding fields instead of breaking old ones. Together these catch and fix drift instead of letting it accumulate silently.

This is called 'listen to yourself' - the service treats publishing the event as the single source of truth, and only updates its own database in reaction to consuming that event back, so there's just one write path instead of two independent ones.

Not every part of the system benefits from going async. If people need an instant yes/no answer, if two things must happen together perfectly, or if the team can't yet trace bugs across services, staying with direct calls is often safer.

Split the process: keep simple, independent side-effects (like sending analytics or a receipt email) as choreographed event subscribers, and wrap the complex, ordered, time-bound core steps in a small orchestrator. The catch: now there are two coordination styles in one flow, and without a clear, enforced boundary, teams gradually blur the line and recreate the same confusion inside the hybrid.

Send a medium-sized event with the commonly needed fields plus a reference (like a claim check) that lets consumers who truly need the big or sensitive parts fetch them separately, rather than sending everything to everyone. Event sourcing, if used internally, is a separate decision about how the order service stores its own history - it doesn't have to leak into what gets published externally.

If the event being published isn't critical - losing or duplicating it occasionally causes no real harm, or the same information can be recovered another way - then adding an outbox table and a relay process might be more complexity than the problem is worth.