The Event Log

• A log is the simplest durable data structure there is: bytes appended to the end of a file, never modified in place. Position in that file is the entire addressing scheme. That is why an offset is meaningful, monotonic and cheap — it is not an index into a mutable structure, it is a byte position in an immutable one (Write-Ahead Logging).
• Immutability is what makes a position a durable contract. If a record could change, an offset would only tell you where to look, not what you would find. Because it cannot, "I processed up to offset 4,812" is a complete, restartable statement of progress (Offsets and Commits).
• The log stores changes; a table stores the result of applying them. You can always derive the table from the log by folding the records forward. You can never derive the log from the table, because the table forgot. A log is strictly more information than the state it produces — that asymmetry is the entire argument for this module.
• Reading is non-destructive. A reader holds its own position; the log does not know or care how many readers exist, and one reader falling behind changes nothing for the others. This is what makes the same log serve a real-time alerting consumer, an hourly warehouse loader and a batch reprocess simultaneously (The Event-Driven Data Platform).
• Ordering is a property of a *single* log. Two records in one log have an unambiguous before-and-after. Two records in two different logs have none, and no amount of timestamping recovers it, because the clocks belong to different machines (Topics and Partitions).

One row per order, updated in place as the order progresses. Consumers poll the table for rows whose `updated_at` moved, and reconstruct what changed by diffing against what they stored last time.

One immutable record per change, appended in order. Consumers read forward from a position they own, and the current state is whatever the fold produces at their position.

Log (append-only, offsets never reused)

  offset  event                       payload
  ------  --------------------------  -----------------------------------
  4810    OrderPlaced                 {order:7731, total:120.00}
  4811    PaymentCaptured             {order:7731, amount:120.00}
  4812    ShippingAddressCorrected    {order:7731, city:"Leipzig"}
  4813    OrderShipped                {order:7731, carrier:"DHL"}

Fold forward  ->  table row (one row, three facts destroyed)

  order_id  total   status    city      updated_at
  --------  ------  --------  --------  ----------
  7731      120.00  shipped   Leipzig   ...

Questions the table cannot answer:
  - what city was this shipping to before the correction?
  - how long did payment-to-ship take?
  - did a correction happen at all?

• Model events as facts in the past tense — OrderPlaced, PaymentCaptured, AddressChanged — not as instructions. A fact stays true no matter how many consumers read it or when; a command implies exactly one recipient who is supposed to act, which is a different shape with different delivery needs (Commands vs Events).
• Put enough in each record that a consumer can act without calling back into the producing system. A record carrying only {order_id} forces every consumer to query the source at read time, which re-couples them to it and makes replay meaningless — you would be replaying against today's state, not the state at the time.
• Give every record a stable business identity — an event id, or a natural key plus a source sequence — so downstream deduplication has something to work with when redelivery happens, and it will (Deduplication).
• Carry the event time on the record, assigned by the producer, distinct from whenever the log or a consumer sees it. Every correctness question in stream processing turns on having that field (Event Time).
• Write the schema down and version it at the boundary, because the log outlives every consumer that reads it and a record written today will be read by code that does not exist yet (Schema Registry).
• Land the raw log output immutably before transforming it. The log's retention is finite; your raw layer's does not have to be, and the two together are what make a six-month reprocess possible (The Raw Landing Zone).

• Durability of an appended record, once acknowledged under whatever replication setting the producer asked for. A producer that does not wait for replication has a weaker guarantee than the log is capable of, and this is a producer-side decision, not a broker property.
• Ordering within one log, by offset, and nothing across logs. This is the guarantee people most often over-read: "the log is ordered" is true and much narrower than it sounds (Topics and Partitions).
• Immutability of a written record. This is the strongest thing a log promises and the one everything else is built on.
• Delivery is at-least-once by default in every real system — producers retry on ambiguous acknowledgement, consumers restart from their last committed position. Duplicates are normal traffic, not an incident (At-Least-Once Delivery).
• No completeness guarantee. The log promises that what was written is there; it promises nothing about whether everything that happened was written. That gap is the producer's, and only reconciliation against the source closes it (Reconciliation).
• No guarantee that the record means what the consumer thinks. A schema check verifies shape; nothing verifies that amount is still gross rather than net (Semantic Changes).