Event-Source the Write Path

An order management system updates order rows in place: every status change overwrites the previous one. The business now needs a full audit history, and the support team wants to answer "what did this order look like at 14:32?". Redesign the write path so state changes are stored as an append-only sequence of events.

Context

Event sourcing stores every state change as an immutable event instead of overwriting the current state. You gain a complete audit trail, the ability to rebuild any past state, and natural decoupling between the write path and any number of read models. The cost is eventual consistency between write and read sides and more moving parts. Reach for it when history IS the requirement — auditing, finance, order lifecycles; avoid it for simple CRUD where current state is all that matters.

Requirements

•Replace the in-place UPDATE with an append-only event store (events are immutable facts: OrderCreated, OrderPaid, OrderShipped)
•Add a projection worker that consumes events and builds/updates a read model
•Route read queries to the read model, not the event store

Non-Functional Requirements

•Full history must be reconstructable from the event store alone

Constraints

•Focus on the write/read topology — ignore snapshotting, event versioning, and specific store technology

Evaluation Criteria

Evaluation criteria and weights will be revealed after you submit your solution. This ensures a fair assessment of your design skills.

Ready to solve this challenge?

Draw your architecture diagram, explain your design decisions, and get AI-powered feedback.

For the best experience, design challenges on a desktop or tablet — drawing the architecture on a phone is hard.

Start drawing nowNo account needed to draw. Sign up only to see your score (2 free evaluations).Already have an account? Sign in