Original practice scenario: A hypothetical banking app lets customers reschedule a branch appointment while staff edit available capacity. Design consistent booking changes under retries.
Read model answer +
Treat a reschedule as moving one identified booking between capacity-constrained slots. Cancelling first and creating later can leave the customer without a booking when the new slot fills.
Work through it
Give slots and bookings stable identities and versions, checking eligibility and capacity on the authoritative service rather than relying on a displayed availability cache.
Reserve the new slot and release the old slot within one transaction where possible, or use a recoverable hold workflow with a clear expiration and final outcome.
Bind retries to the intended booking change, returning the stored result and exposing concurrent staff changes as conflicts requiring a fresh choice.
Tradeoffs to discuss
Temporary holds improve user experience but reduce visible capacity until expiration; immediate transactions are simpler when both slots share one authority.
Common pitfalls
A repeated request must not create several appointments under different booking identifiers.
Validate time zones, holidays and daylight-saving boundaries instead of storing only a local clock label.
Original practice scenario: A hypothetical banking report groups transactions by account status, but status history includes closures and reopenings. How should a historical query avoid using today's status?
Read model answer +
Join each transaction to an effective-dated status interval. Current account state is a useful operational view but is not a replacement for historical status at the event time.
Work through it
Define whether status takes effect at event time or posting time, then store non-overlapping intervals with account identity and an explicit boundary convention.
Join using the declared timestamp and interval, validating that each transaction has exactly one applicable status or a visible unknown-status exception.
Handle backdated corrections through versioned snapshots and compare transaction counts and amounts before and after enrichment to detect multiplication or omission.
Tradeoffs to discuss
Maintaining interval history adds storage and correction logic but supports reproducible reporting; a current-state table is cheaper for present-tense questions.
Common pitfalls
Avoid inclusive boundaries at both ends when adjoining intervals share a timestamp.
Do not use arbitrary row ordering to resolve overlapping statuses; surface the conflicting source history.
