Event-driven architecture & messaging

A message broker is a middleman server that receives messages from senders and delivers them to receivers, so the two sides never talk directly. This lets one side keep working even if the other is slow, down, or busy.

A DLQ is a separate queue where messages that fail processing repeatedly get moved to, instead of blocking the main queue or being retried forever, so the app keeps working while someone looks at the bad message later.

At-most-once can lose a message but never repeats it. At-least-once never loses a message but can repeat it. Exactly-once means every message is processed once, no loss and no duplicates. Most real systems use at-least-once plus deduplication.

An offset is a bookmark marking how far a consumer has read in a partition. Since the log isn't deleted after reading, moving the bookmark backward lets the consumer re-read and reprocess old events.

Idempotent means doing something twice has the same effect as doing it once. The consumer remembers which messages it already handled (by ID) and skips reprocessing the effect, like charging money again, even if the message arrives more than once.

Choreography: each service reacts to events from other services on its own, like dancers who each know their part with no director. Orchestration: one central 'conductor' service tells every other service exactly what to do and when.

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.

A command asks the system to do something and can be refused, like a request. An event says something already happened and is a fact - you can't refuse a fact, only react to it.

The read copy of the data updates a little after the write copy, through a background sync step. Until that catches up, queries can show old data. That gap in time is called the lag window (or replication lag).

CQRS just means writes and reads use different models. Event Sourcing means you store every change as an event instead of overwriting data. You can do CQRS without Event Sourcing, but when a team does use Event Sourcing, the event log naturally becomes the write side and the read side is built from those events.

A projection is a read-only copy of your data, shaped for easy querying, that's kept updated by watching events from the part of the system that handles writes. Teams build it because the write data is often shaped for correctness, not for fast, flexible reading.

A read model is a copy of your data shaped exactly for what a screen or report needs to show, separate from the data structure used to save changes. It exists so reading is fast and simple, and writing stays focused on correctness.

The command side loads the past events for that thing, checks the business rules, creates one new event describing what happened, and appends it. Nothing is overwritten, only added.

An event store only lets you add new records, never change or delete old ones. Instead of overwriting a row to reflect current state, it keeps every change as its own permanent entry, in order.

Old events are stored forever and get replayed to rebuild state. If you change what a field means without a plan, old events break the code that reads them. Upcasting is a small translator that turns an old-shaped event into the new shape before your code sees it, so replay still works.

A projection is a separate copy of your data, built by reading through the history of every change (events) and turning it into a simple, fast-to-search table - like building an index from a diary instead of re-reading the whole diary every time you need an answer.

The system starts with an empty/default state and applies each stored event for that aggregate, one by one, in the order they happened, updating the state a bit with each event. Doing this to rebuild state is called rehydration; the loop that folds each event into state is the fold/reduce pattern.