Schema Evolution & CQRS — Series 3

Preview — 3 of 10 questions

An event-sourced orders aggregate has accumulated 50,000 events over its lifetime. Rebuilding its current state means replaying every single one from the start, which is getting noticeably slow. What's the standard technique to address this?

ADelete old events once the aggregate is old enough — event sourcing tolerates losing history

BSwitch the aggregate to CQRS, which automatically eliminates the need to replay events

CSnapshotting requires abandoning event sourcing entirely in favor of a normal CRUD table

DPeriodically persist a snapshot: the aggregate's fully computed state as of a specific event sequence number. Rebuilding state then means loading the most recent snapshot and replaying only the (much smaller number of) events that occurred after it, instead of the entire history from event 1

In a CQRS system, a user submits a write (command), then immediately navigates to a page reading from the projected read model. What consistency issue can occur, and how do CQRS systems commonly handle it?

AThis is never an issue — the read model is always updated synchronously as part of the same transaction as the write

BThis only affects systems using PostgreSQL logical replication, never message-queue-based projections

CCQRS makes reads strictly slower than writes, but consistency is never actually a concern

DThe read model can lag behind the write model, since projections are typically updated asynchronously (e.g. via a message queue or CDC stream) after the write commits — so the user might briefly not see their own just-made change. Common mitigations include an optimistic client-side UI update that doesn't wait for the projection, returning the freshly-written data directly from the command response rather than re-reading the projection, or a "read-your-writes" trick like routing that specific user's next read to a replica known to be caught up

An application needs to change a columns default from `pending` to `draft'` for all future inserts, without affecting existing rows or requiring downtime. Is this safe to do directly?

ANo — changing a column's DEFAULT always requires rewriting every existing row to apply the new default retroactively

BThis requires the expand-contract pattern across two separate deploys

CChanging a DEFAULT value can only be done by dropping and recreating the entire table

DYes — ALTER TABLE orders ALTER COLUMN status SET DEFAULT 'draft'; only changes what value future inserts (that omit the column) will use; it doesn't touch any existing row's stored value at all, and is a fast, metadata-only change with no table rewrite or meaningful lock duration

Answer all 10 questions (7 more), see explanations for every answer, and track your score.