Decide whether a separate account summary read model earns its lag
The account summary joins five tables and is the slowest synthetic endpoint. A CQRS proposal introduces a projection, but support must see a just-disabled booking channel immediately after issuing the command.
- Focused work estimate
- 5h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Read-model design · Consistency · Performance analysis · Tradeoff analysis
Estimated field mix
- System design40%
- Database engineering30%
- Performance engineering30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- CQRSCompare
Compare command/query separation with an indexed query using freshness, rebuild, and write-cost requirements rather than assuming a projection is necessary.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic.
Setup prerequisites
- REST contracts
- Tenant authorization
- Transactions
- Dependency injection
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- PMIGRATE-101 · Put legacy account lookups behind a contract the replacement can keep
- PMIGRATE-102 · Remove the process-wide current-tenant account client
- PMIGRATE-103 · Separate account policy from legacy SQL and replacement storage
- PMIGRATE-104 · Shadow account reads without duplicating booking-channel writes
Acceptance criteria
- Compare an indexed transactional query with a separate projection using a declared synthetic dataset and equivalent authorization boundaries.
- For the projection option, expose freshness/version semantics and define a read-after-write path that cannot show a disabled channel as enabled after an acknowledged command.
- Document latency, write cost, rebuild behavior, and operational complexity; implement the selected option and justify rejecting the other.
Implementation constraints
- CQRS does not require separate services or event sourcing here; evaluate command/query separation within the existing local application.
Verification to include
- Measure both options with identical account counts and query mix, reporting warmup and repeated-run variability.
- Pause projection updates, issue a disable command, and exercise the declared freshness strategy; test an interrupted rebuild without cross-tenant reads.
Deliverables
- Read-model comparison, selected implementation, and freshness/rebuild contract
Rollout and recovery
Canary the selected read path for one synthetic tenant; retain the transactional path until freshness and rebuild failure checks pass.
Value of the work
For the engineer: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change.
For the team: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.