35 / 60 · Low-Level Design

ATM — Production Architecture

All designs

Authenticate users, dispense cash, and coordinate account transactions with device state.

24/7 terminal · finite cash cassettes · bank network failures
1. High-level architecture and animated call flow

Choose a path, then play or step through exactly how the call moves between components.

← / → step · Space play
CLOUD / MULTI-AZ DEPLOYMENT ATM · PRODUCTION TOPOLOGY 14 named components · solid = request/data dependency · warm curve = control, event, or repair path MULTI-ZONE · VERSIONED · REPLAYABLE 01 · REQUEST & CONTROL02 · DOMAIN & COORDINATION03 · DATA, ASYNC & OPERATIONSrequestauthenticateroutevalidateread / reservecommitpublishconsumeprojectobserverepairreconcileinvalidatepolicy snapshotevent streamtelemetry 01 SERVICE Card Reader domain subsystem 02 EXTERNAL Keypad/Display interaction boundary 03 SERVICE ATM Controller domain subsystem 04 SERVICE Session StateMachine domain subsystem 05 SECURITY PIN/Auth Adapter decision & coordination 06 SERVICE TransactionOrchestrator decision & coordination 07 SERVICE Bank Core Adapter domain subsystem 08 DATA Cash Inventory authoritative durable state 09 SERVICE DenominationStrategy decision & coordination 10 SERVICE Cash Dispenser domain subsystem 11 SERVICE Dispense Sensors domain subsystem 12 SERVICE Receipt Printer domain subsystem 13 STREAM Local Journal durable ordered events 14 EXTERNAL Reconciliation/Operator interaction boundary externaledgeservicedatastreamsecurityops
Step 1 / 6Keypad / Display

The caller starts the operation at Keypad / Display with a stable request and retry identity.

  1. 01 · Keypad / DisplayThe caller starts the operation at Keypad / Display with a stable request and retry identity.
  2. 02 · ATM ControllerCapture card token, authenticate PIN through bank adapter, and establish bounded session.
  3. 03 · PIN / Auth AdapterValidate amount and compute a feasible denomination plan from versioned cassette counts.
  4. 04 · Transaction OrchestratorAuthorize/reserve funds at bank using request ID before commanding hardware.
  5. 05 · Cash InventoryDispense, verify sensors, then finalize debit; uncertain hardware outcome enters reconciliation.
  6. 06 · Local JournalJournal every transition locally so network/power recovery can compare bank and physical cash.
2. Critical request and recovery sequence
MUTATION / COMMITCard ReaderACTOR 01Keypad/DisplayACTOR 02Session StateMachineACTOR 03Cash InventoryACTOR 04ONLINE / READ + RECOVERYCard ReaderACTOR 01ATM ControllerACTOR 02TransactionOrchestratorACTOR 03Reconciliation/OperatorACTOR 04Capture card token, authenticate / PIN through bank adapter, andValidate amount and compute a / feasible denomination plan fromAuthorize/reserve funds at bank / using request ID before commandingcommitted result + eventAuthorize/reserve funds at bank / using request ID before commandingDispense, verify sensors, then / finalize debit; uncertain hardwareJournal every transition locally so / network/power recovery can comparecached/read result + cursortimeout → retry same identity → read committed truth → reconcile

Card Reader

  • Owns one bounded domain decision, transition, or operational capability.
  • Partitioned by aggregate/key and guarded by version, uniqueness, or fencing.

Keypad / Display

  • Owns one bounded domain decision, transition, or operational capability.
  • Partitioned by aggregate/key and guarded by version, uniqueness, or fencing.

ATM Controller

  • Owns one bounded domain decision, transition, or operational capability.
  • Partitioned by aggregate/key and guarded by version, uniqueness, or fencing.

Session State Machine

  • Owns one bounded domain decision, transition, or operational capability.
  • Partitioned by aggregate/key and guarded by version, uniqueness, or fencing.

Complete System Design Tutorial

The design separates the latency-sensitive online path, the correctness-critical durable transition, and asynchronous projection or repair work. Each chapter below explains one decision shown in the diagrams.

1. Requirements and scope

Functional requirements

  • Execute the primary atm workflow and return an observable result.
  • Expose the concrete operations shown below with stable retry identities.
  • Allow operators to inspect, disable, repair, or replay ambiguous state.
  • Keep derived analytics and notifications off the correctness-critical path.

Non-functional requirements

  • Design for 24/7 terminal · finite cash cassettes · bank network failures.
  • Protect the named business invariant under concurrency and partial failure.
  • Scale by an explicit aggregate/partition key without one global mutex.
  • Degrade intentionally when cache, queue, store, or regional ownership is unavailable.
Primary invariant: every object transition is legal and atomic at one aggregate boundary.
↑ top

2. Capacity assumptions

State assumptions before choosing technology. The supplied workload is 24/7 terminal · finite cash cassettes · bank network failures. Convert it into peak throughput, retained records, bandwidth, and failure budget; then connect each number to a component.

DimensionWorking estimateDesign implication
Traffic24/7 terminal · finite cash cassettes · bank network failuresSeparate online compute, durable state, and asynchronous consumers.
Peak factor5–10× averageAdmission control, autoscaling headroom, and hot-key protection.
Stored statewrite rate × retention × record bytesPartition count, indexes, compaction, backup, and archival tier.
Networkpeak operations × payload sizeBatching, compression, edge placement, and egress budget.
Availability99.9–99.99%Multi-zone replicas, tested failover, and dependency error budgets.
RecoveryRPO/RTO by invariantAck boundary, replay retention, reconciliation, and operator runbooks.
Do not cargo-cult the numbers: show the arithmetic, name the uncertain variable, and say which production metric will replace the interview estimate.
↑ top

3. API and data model

INSERT_CARD / AUTHENTICATEdevice session
WITHDRAW(account, amount, request_id)
DISPENSE(plan)hardware command
RECONCILE(journal_batch)operator/bank settlement

Authoritative records and indexes

atm_session(session_id, card_token, auth_state, expires_at)

withdrawal(request_id, account_ref, amount, state, bank_ref)

cassette(denomination, count, version)

journal(sequence, request_id, event, device_state)

Command and event envelopes

# Command envelope
operation: INSERT_CARD / AUTHENTICATE
request_id: req_01J...
idempotency_key: idem_7f2...
aggregate_key: atm_123
expected_version: 17
payload: {...}

# Durable event
event_id: evt_01J...
aggregate_key: atm_123
event_type: atm_committed
schema_version: 3
trace_id: tr_8ac...

The authoritative aggregate and idempotency record share a transactional or conditional-write boundary. Event streams, search indexes, caches, analytics, and dashboards are rebuildable projections.

↑ top

4. Why this architecture and what it costs

The boxes are not a shopping list. Each boundary exists because it owns a different invariant, scaling dimension, data lifecycle, security policy, or failure domain. The table makes those choices explicit and shows when the design should remain simpler.

ComponentOwned responsibilityWhy separate itRejected alternativeCost and evolution trigger
Card ReaderOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Capture card token, authenticate PIN through bank adapter, and establish bounded session.Separates a distinct scale, ownership, policy, or failure boundary. It prevents the external caller from also owning the contract and failure behavior of Keypad / Display.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Debit succeeds but cash jams” to the external caller.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Card Reader boundary before extracting or scaling it.
Keypad / DisplayOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Validate amount and compute a feasible denomination plan from versioned cassette counts.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Card Reader from also owning the contract and failure behavior of ATM Controller.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Cash dispenses after network timeout” to Card Reader.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Keypad / Display boundary before extracting or scaling it.
ATM ControllerOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Authorize/reserve funds at bank using request ID before commanding hardware.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Keypad / Display from also owning the contract and failure behavior of Session State Machine.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Cassette count differs from sensors” to Keypad / Display.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the ATM Controller boundary before extracting or scaling it.
Session State MachineOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Dispense, verify sensors, then finalize debit; uncertain hardware outcome enters reconciliation.Separates a distinct scale, ownership, policy, or failure boundary. It prevents ATM Controller from also owning the contract and failure behavior of PIN / Auth Adapter.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Power fails mid-dispense” to ATM Controller.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Session State Machine boundary before extracting or scaling it.
PIN / Auth AdapterOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Journal every transition locally so network/power recovery can compare bank and physical cash.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Session State Machine from also owning the contract and failure behavior of Transaction Orchestrator.Embed policy in every caller. Rules then drift by deployment version and emergency changes require fleet-wide redeployment. Here that simpler choice would couple “Card retained during session fault” to Session State Machine.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the PIN / Auth Adapter boundary before extracting or scaling it.
Transaction OrchestratorOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Capture card token, authenticate PIN through bank adapter, and establish bounded session.Separates a distinct scale, ownership, policy, or failure boundary. It prevents PIN / Auth Adapter from also owning the contract and failure behavior of Bank Core Adapter.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Debit succeeds but cash jams” to PIN / Auth Adapter.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Transaction Orchestrator boundary before extracting or scaling it.
Bank Core AdapterOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Validate amount and compute a feasible denomination plan from versioned cassette counts.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Transaction Orchestrator from also owning the contract and failure behavior of Cash Inventory.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Cash dispenses after network timeout” to Transaction Orchestrator.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Bank Core Adapter boundary before extracting or scaling it.
Cash InventoryOwns authoritative versioned state or immutable evidence. In this design it participates in: Authorize/reserve funds at bank using request ID before commanding hardware.Defines the source of truth and commit boundary. It prevents Bank Core Adapter from also owning the contract and failure behavior of Denomination Strategy.Let each service persist its own interpretation. That removes one clear commit boundary and makes retries, support, and reconciliation ambiguous. Here that simpler choice would couple “Cassette count differs from sensors” to Bank Core Adapter.Costs schema migration, replication, backup, and shard ownership. Split storage only when access patterns, retention, or compliance boundaries materially differ. Measure the latency, saturation, lag, or mismatch at the Cash Inventory boundary before extracting or scaling it.
Denomination StrategyOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Dispense, verify sensors, then finalize debit; uncertain hardware outcome enters reconciliation.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Cash Inventory from also owning the contract and failure behavior of Cash Dispenser.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Power fails mid-dispense” to Cash Inventory.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Denomination Strategy boundary before extracting or scaling it.
Cash DispenserOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Journal every transition locally so network/power recovery can compare bank and physical cash.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Denomination Strategy from also owning the contract and failure behavior of Dispense Sensors.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Card retained during session fault” to Denomination Strategy.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Cash Dispenser boundary before extracting or scaling it.
Dispense SensorsOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Capture card token, authenticate PIN through bank adapter, and establish bounded session.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Cash Dispenser from also owning the contract and failure behavior of Receipt Printer.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Debit succeeds but cash jams” to Cash Dispenser.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Dispense Sensors boundary before extracting or scaling it.
Receipt PrinterOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Validate amount and compute a feasible denomination plan from versioned cassette counts.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Dispense Sensors from also owning the contract and failure behavior of Local Journal.Keep this behavior inside an adjacent service. Prefer that simpler option until independent scale, ownership, policy, or failure isolation is measurable. Here that simpler choice would couple “Cash dispenses after network timeout” to Dispense Sensors.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Receipt Printer boundary before extracting or scaling it.
Local JournalPreserves durable ordering, replay, and consumer checkpoints. In this design it participates in: Authorize/reserve funds at bank using request ID before commanding hardware.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Receipt Printer from also owning the contract and failure behavior of Reconciliation / Operator.Call every downstream consumer synchronously. That couples user latency and availability to analytics, notification, indexing, and audit dependencies. Here that simpler choice would couple “Cassette count differs from sensors” to Receipt Printer.Costs eventual consistency, schema evolution, replay tooling, idempotent consumers, and lag operations. Earn it when bursts or downstream failure must not block acknowledgment. Measure the latency, saturation, lag, or mismatch at the Local Journal boundary before extracting or scaling it.
Reconciliation / OperatorOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Dispense, verify sensors, then finalize debit; uncertain hardware outcome enters reconciliation.Proves correctness and supports controlled recovery. It prevents Local Journal from also owning the contract and failure behavior of operators and repair tooling.Infer correctness from request logs. Logs do not prove durable business state, detect silent drift, or safely repair ambiguous outcomes. Here that simpler choice would couple “Power fails mid-dispense” to Local Journal.Costs an interface, deployment, telemetry, ownership, and failure mode. Keep it in-process first; extract when independent scale or reliability pays for the boundary. Measure the latency, saturation, lag, or mismatch at the Reconciliation / Operator boundary before extracting or scaling it.
Decision 01

Chosen boundary vs simpler monolith

Model withdrawal as a saga: authorize, reserve account funds, dispense, then finalize or compensate.

A single deployable with one transactional store is the right starting point for a small atm workload. The proposed boundary becomes justified when model withdrawal as a saga: authorize, reserve account funds, dispense, then finalize or compensate. Separating it contains the named failure “Debit succeeds but cash jams” without placing unrelated work on the critical path.

Decision 02

Correctness vs availability

Separate device interfaces from transaction logic so cash, card reader, printer, and network faults are testable.

The design coordinates only where every object transition is legal and atomic at one aggregate boundary. Everywhere else it accepts bounded staleness or asynchronous propagation. The alternative—strong coordination for every projection—simplifies the mental model but increases tail latency and turns partitions into broad write unavailability.

Decision 03

Operational cost and evolution

Record an append-only audit trail and never infer financial truth solely from local ATM state.

This choice adds dashboards, ownership, schema compatibility, capacity planning, and recovery runbooks. Start with the minimum topology that supports “Authorize/reserve funds at bank using request ID before commanding hardware.” and extract another service only when measured throughput, blast radius, data lifecycle, or team ownership changes independently.

Why this design: the synchronous path contains only the decisions required to protect every object transition is legal and atomic at one aggregate boundary. Durable projections, notifications, indexing, analytics, and repair are isolated so their load or failure cannot corrupt the acknowledged operation.
Correctness boundary

Model withdrawal as a saga: authorize, reserve account funds, dispense, then finalize or compensate.

Scale boundary

Separate device interfaces from transaction logic so cash, card reader, printer, and network faults are testable.

Operational boundary

Record an append-only audit trail and never infer financial truth solely from local ATM state.

↑ top

5. Critical flow and algorithm

01

Capture card token, authenticate PIN through bank adapter, and establish bounded session.

02

Validate amount and compute a feasible denomination plan from versioned cassette counts.

03

Authorize/reserve funds at bank using request ID before commanding hardware.

04

Dispense, verify sensors, then finalize debit; uncertain hardware outcome enters reconciliation.

05

Journal every transition locally so network/power recovery can compare bank and physical cash.

Retry-safe mutation skeleton

identity = authenticate(request)
prior = idempotency.get(identity, request.key)
if prior: return prior.result

current = authoritative_store.read(partition_key)
next_state, events = domain.transition(current, request)
authoritative_store.compare_and_set(current.version, next_state)
idempotency.commit(request.key, next_state.result)
outbox.append(events)
return next_state.result
Exactly-once business effect: the network can duplicate requests. Stable identities, conditional state transitions, immutable event IDs, and reconciliation make the user-visible effect happen once.
↑ top

6. Caching, hot keys, and backpressure

Cache policy

Add a cache only for a measured repeated read; do not place mutable correctness state in a disposable layer.

Hot partition or tenant

Measure per-key and per-tenant skew. Replicate safe reads, isolate the offender, salt only when ordering permits, and enforce budgets.

Backpressure

Bound queues, buffers, connection pools, and concurrency. Shed low-priority work and scale from lag/oldest-item age rather than CPU alone.

Stampede and retry storms

Use single-flight/coalescing, jittered expiry, bounded retries, exponential backoff, and circuit breakers so one dependency failure does not multiply traffic.

Cache outage rule: never allow every miss to fall through simultaneously. Use local protection, request coalescing, circuit breakers, bounded pools, and controlled fallback.
↑ top

7. Partitioning and consistency

partition = stable_hash(primary_or_aggregate_key) → shard owner
write = conditional_update(expected_version)
read_projection = versioned and rebuildable

Strong boundary

every object transition is legal and atomic at one aggregate boundary. Use a uniqueness constraint, serializable/conditional write, expected version, or fencing token at this boundary.

Eventual boundary

Analytics, notifications, search, read models, and operational dashboards may lag when freshness is observable and replay exists.

OperationConsistencyReason
Authoritative mutationConditional / serializableProtect uniqueness, ownership, money, inventory, order, or legal state transition.
Read after own writePrimary, session token, or cache warmThe caller must observe the result it just committed.
Ordinary read projectionBounded stale where safeReplicas and caches improve latency when version/freshness is visible.
Analytics and operationsEventual + replayFreshness is less important than isolating the online path.
  • Route every mutation for one aggregate to one owner/partition epoch.
  • Use cursors rather than offsets for changing ordered collections.
  • Retain tombstones until replication and repair windows close.
  • Move shard ownership through versioned maps and dual-read verification.
↑ top

8. Failure drills and recovery

FailureRuntime behaviorRecovery proof
Debit succeeds but cash jamsStop unsafe progress, serve only explicitly safe degraded behavior, and recover from durable state.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.
Cash dispenses after network timeoutQuery/retry with the same operation identity; do not issue a second business effect.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.
Cassette count differs from sensorsStop unsafe progress, serve only explicitly safe degraded behavior, and recover from durable state.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.
Power fails mid-dispenseStop unsafe progress, serve only explicitly safe degraded behavior, and recover from durable state.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.
Card retained during session faultStop unsafe progress, serve only explicitly safe degraded behavior, and recover from durable state.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.

Recovery checkpoint

# Recovery checkpoint
scenario: Debit succeeds but cash jams
operation_id: op_01J...
aggregate_key: atm_123
last_durable_version: 18
projection_checkpoint: partition-07@offset-482901
retry_policy: same_identity / bounded_backoff
reconciliation_status: pending
owner: Reconciliation / Operator

Every dependency needs a timeout, retry budget, circuit policy, and explicit fail-open, fail-closed, stale, or read-only mode. “Highly available” is incomplete until degraded behavior is named.

↑ top

9. Security, regions, and observability

Security and abuse

  • Authenticate at ingress and authorize the exact resource/tenant on every operation.
  • Encrypt transport and durable data; tokenize or isolate sensitive material.
  • Rate-limit by tenant, actor, resource, and network; detect enumeration and anomalous fan-out.
  • Redact secrets and personal data before logs or analytical storage.
  • Audit privileged mutations, support access, policy changes, and forced recovery.

Signals that prove correctness

  • User-visible success rate and p50/p95/p99 latency.
  • Timeouts, circuit state, saturation, and replica health by dependency.
  • Queue lag, oldest-item age, retries, and dead-letter growth.
  • Conflict, duplicate-suppression, and reconciliation mismatch counts.
  • Business drill: Debit succeeds but cash jams — alert before the user-visible invariant is violated.

Regional evolution

  1. Begin multi-zone with tested failover, backups, and reconciliation.
  2. Add global stateless ingress and regional read projections.
  3. Keep one write owner per aggregate or partition where coordination is expensive.
  4. Move ownership with epochs/fencing; avoid silent simultaneous writers.
  5. Use expand/contract schemas, canaries, shadow reads, and reversible cutovers.
↑ top

10. Interviewer follow-ups

What if cash jams after debit?

Model withdrawal as a saga: authorize, reserve account funds, dispense, then finalize or compensate. Walk the concrete lifecycle step “Capture card token, authenticate PIN through bank adapter, and establish bounded session.” Then test it against “Debit succeeds but cash jams”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

How are denominations selected?

Separate device interfaces from transaction logic so cash, card reader, printer, and network faults are testable. Walk the concrete lifecycle step “Validate amount and compute a feasible denomination plan from versioned cassette counts.” Then test it against “Cash dispenses after network timeout”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

How are PIN retries handled?

Record an append-only audit trail and never infer financial truth solely from local ATM state. Walk the concrete lifecycle step “Authorize/reserve funds at bank using request ID before commanding hardware.” Then test it against “Cassette count differs from sensors”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

What if the bank network times out?

Model withdrawal as a saga: authorize, reserve account funds, dispense, then finalize or compensate. Walk the concrete lifecycle step “Dispense, verify sensors, then finalize debit; uncertain hardware outcome enters reconciliation.” Then test it against “Power fails mid-dispense”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

How does cash replenishment work?

Separate device interfaces from transaction logic so cash, card reader, printer, and network faults are testable. Walk the concrete lifecycle step “Journal every transition locally so network/power recovery can compare bank and physical cash.” Then test it against “Card retained during session fault”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

Answer pattern: state the invariant, choose a mechanism, walk one failure, name the recovery signal, and explain the cost of the alternative.
↑ top

11. How to present this in 45 minutes

TimeWhat to cover
0–5 minClarify scope, workload, SLOs, and the correctness invariant.
5–10 minEstimate throughput/storage and define concrete APIs and records.
10–20 minDraw online, durable-write, and asynchronous/repair paths.
20–30 minExplain the exact lifecycle, partition key, and concurrency control.
30–38 minDiscuss caching, hot keys, replication, and backpressure.
38–43 minRun failure drills, security, observability, and regional evolution.
43–45 minSummarize the five most important choices and trade-offs.

Final decision summary

Invariantevery object transition is legal and atomic at one aggregate boundary.
PartitioningStable aggregate/key hash with versioned ownership and measured hot-key isolation.
CommitExpected version or uniqueness at the authoritative state boundary.
Async workDurable outbox/log, idempotent consumers, checkpoints, and replay.
RecoverySame operation identity, durable truth lookup, and business reconciliation.

Closing summary

CLOSING “The design protects every object transition is legal and atomic at one aggregate boundary. The online path stays bounded, authoritative state is versioned and partitioned, and asynchronous work is replayable and observable.”
↑ top