Skip to content
Atlas, your robot learning host

Interim portrait

Atlas · Foundations event-sourcing

Hello, little human. I am Atlas. One useful idea is plenty for a beginning. Read the explanation, then explore an example.

Choose your robot No recording yet · text complete
concept for junior engineers
  • database

Event Sourcing

Keep the accepted event stream as the authoritative record and reconstruct the modeled state by applying it in order.

Tune in, human.

Reviewed videos and Shorts

Captions requested · no autoplay

Finding reviewed videos…

    Keep the useful bits, human.

    Beginner field notes

    Choose explanation level
    • Event sourcing keeps the accepted changes as the authoritative record, rather than keeping only the latest value.
    • To find an entity’s current state, replay its recorded events in the defined order using the application’s rules.
    • A separate activity log does not by itself make an application event-sourced. Ask whether the event history is the source used to reconstruct state.
    See a worked example

    Rebuild T7 and ignore one duplicate delivery

    One reviewed sample, shared across levels. Nothing here runs on your computer.

    Example review recorded 2026-10-16 · version 1.

    Example input · do not paste
    Authoritative T7 stream:
Sequence 1, event e1: TaskCreated, title “Label seed box”.
Sequence 2, event e2: TaskCompleted.
Sequence 3, event e3: TaskReopened.
Rules: start with no task; Created sets Open/count 0; Completed sets Done and increases historical completion count; Reopened sets Open.
Projection receives e1, e2, duplicate e2, e3. IDs already applied are skipped. No missing/out-of-order events, external actions or concurrent appends are modeled.
    Example output · do not paste
    After e1: Open, completion count 0.
After e2: Done, completion count 1.
After duplicate e2: unchanged, Done/count 1.
After e3: Open, completion count 1.
Rebuilding a fresh projection once from authoritative sequences 1–3 yields Open/count 1.

    The duplicate did not become a new event in the authoritative stream. Without the stated ID handling, blindly increasing the counter for every delivery would yield 2. The result depends on this stream’s order and rules; it does not claim global ordering, universal exactly-once delivery or safe replay of external side effects.

    Sources for this sample

    Visual

    The authoritative ordered events rebuild the task state and its board projection without sending external notifications.

    The reviewed description and complete diagram source are available here.

    Read the complete diagram source

    This is the source for the reviewed diagram, not a command to run.

    flowchart LR
  E["Accepted ordered event stream"] --> R["Replay each unique event"]
  R --> S["Task state: Open; completions: 1"]
  R --> P["Rebuilt board projection"]
    Full explanation and primary sources

    Reviewed explanation

    Event sourcing stores accepted changes as events and treats that event stream as the authoritative record for the modeled state. The application reconstructs state by applying those events with defined rules. For Lantern Board, the current task can be rebuilt from TaskCreated, TaskCompleted and TaskReopened. An ordinary diagnostic log beside an independently updated current-state table is not, by that fact alone, this design.

    Reconstruction starts with no task and interprets the ordered stream for T7. TaskCreated establishes Open and zero completions; TaskCompleted sets Done and adds one completion; TaskReopened sets Open without removing that historical completion. The stream therefore reconstructs both today’s Open status and the fact that completion occurred once. The rules and event meanings must stay available; merely keeping names and timestamps is not sufficient.

    The worked example assumes a complete ordered stream, stable interpretation rules and unique event IDs. Its projection consumer may receive an event twice, so it ignores an ID already applied. Duplicate delivery is different from a genuinely new accepted event with its own identity. Concurrent command handlers also need an append contract, such as rejecting an append against an outdated stream version and rechecking the command; an append-only label does not solve conflicts by itself.

    Replay here only rebuilds state. It sends no emails or other external actions; replaying history must not repeat those effects accidentally. Production designs also face evolving event schemas and reconstruction cost, sometimes using snapshots. Those choices add complexity and must justify the pattern. CQRS can use projections from events, but the two patterns are different decisions. This example is an explanation, not instructions for migrating a live database.

    Source collection

    • Microsoft Azure Architecture Center: Event Sourcing pattern

      Used in: Quick notes · Worked example · Lesson text

      Authoritative per-entity event streams, reconstruction, intent, projections, optimistic concurrency, schema/upcast/snapshot boundaries, duplicate effects and cross-entity conflicts.

      An authoritative append-only event stream, reconstruction/projections, ordering, optimistic concurrency, duplicate delivery and pattern costs.

    • Martin Fowler: Event Sourcing (historical draft essay)

      Used in: Worked example · Lesson text

      Reconstructing state by processing recorded events; replay must control external updates and preserve needed historical inputs. The page identifies its historical draft status.

    Notes AI source review · 2026-10-17

    AI source comparison recorded 2026-10-16. Human learner validation is pending.

    Quick quiz · one question

    Replay accepted events without repeating a delivery

    Sample scenario. Synthetic authoritative stream for T7, delivered in order apart from one exact duplicate. Created sets Open/count 0; Completed sets Done and adds one historical completion; Reopened sets Open. Stable IDs and meanings are retained; already-applied IDs are skipped. Replay performs no external actions.

    Starting task
    No task yet
    Duplicate contract
    An already-applied ID with the same event meaning is skipped.
    Delivery 1
    event-a: created
    Delivery 2
    event-b: completed
    Delivery 3
    event-b: completed
    Delivery 4
    event-c: reopened

    What state does this projection reconstruct after the final delivery?

    Answers stay on this device.

    Sources and exercise scope

    Original synthetic exercise. AI comparison against the reviewed lesson recorded on 2026-10-17; the references above state their scope. Human learner validation has not been run. A result here records this attempt; it does not establish mastery.

    Save or adjust this lesson
    Reference notes · file removal and public access

    Robot reference desk

    Understand what can change

    These reviewed public notes are available to everyone. They do not establish that an operation ran or inspect your files, backups or permissions.

    File removal

    Before deleting files: deleting a file can remove it without putting it in Trash or a recycle bin, and recovery is not guaranteed. Check the intended targets and whether a usable backup or recovery option exists before continuing.

    Sources for this note

    Public access

    Before making a resource public: public read access can let anyone view the exposed content, and public write access can allow changes to data. Check the actual audience, exposed content and allowed operations before continuing. This guidance does not inspect or change your permissions.

    Sources for this note

    A link can carry these public reference topics in its fragment. Page scripts, extensions, browser history and copied links can read them. This page attempts to minimize that fragment when JavaScript runs; reloading afterward can lose the selection. No project details or conversation text belong in a lesson link. Privacy details.