32 / 60 · Low-Level Design

Elevator System — Production Architecture

All designs

Schedule cars, serve hall and cabin requests, and preserve safety under concurrent events.

50 floors · 12 cars · sub-second dispatch decision
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 ELEVATOR SYSTEM · 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 EXTERNAL Hall Panel interaction boundary 02 EXTERNAL Cabin Panel interaction boundary 03 SERVICE Building Controller domain subsystem 04 SERVICE Dispatch Strategy decision & coordination 05 SERVICE Request Deduper domain subsystem 06 SERVICE Car Controller domain subsystem 07 SERVICE Car State Machine domain subsystem 08 SERVICE Motion Controller domain subsystem 09 SERVICE Door Controller domain subsystem 10 SERVICE Floor Sensors domain subsystem 11 SERVICE Load Sensor domain subsystem 12 SECURITY Safety Interlock domain subsystem 13 OPS Fault Manager domain subsystem 14 SERVICE Maintenance Console domain subsystem externaledgeservicedatastreamsecurityops
Step 1 / 5Hall Panel

The caller starts the operation at Hall Panel with a stable request and retry identity.

  1. 01 · Hall PanelThe caller starts the operation at Hall Panel with a stable request and retry identity.
  2. 02 · Building ControllerDeduplicate hall/cabin requests and snapshot all eligible car states.
  3. 03 · Safety InterlockDispatch strategy scores direction, distance, load, stops, and service mode.
  4. 04 · Dispatch StrategyAssign request by generation; car controller inserts a legal stop into its plan.
  5. 05 · Fault ManagerState machine commands motion only with doors locked and safety interlocks healthy.
2. Critical request and recovery sequence
MUTATION / COMMITHall PanelACTOR 01Cabin PanelACTOR 02DispatchStrategyACTOR 03MotionControllerACTOR 04ONLINE / READ + RECOVERYHall PanelACTOR 01BuildingControllerACTOR 02Car ControllerACTOR 03MaintenanceConsoleACTOR 04Deduplicate hall/cabin requests and / snapshot all eligible car states.Dispatch strategy scores direction, / distance, load, stops, and serviceAssign request by generation; car / controller inserts a legal stopcommitted result + eventAssign request by generation; car / controller inserts a legal stopState machine commands motion only / with doors locked and safetySensor events advance floor/door / states; faults remove car andcached/read result + cursortimeout → retry same identity → read committed truth → reconcile

Hall Panel

  • Owns client protocol, request identity, retry, and resume behavior.
  • Partitioned by aggregate/key and guarded by version, uniqueness, or fencing.

Cabin Panel

  • Owns client protocol, request identity, retry, and resume behavior.
  • Partitioned by aggregate/key and guarded by version, uniqueness, or fencing.

Building Controller

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

Dispatch Strategy

  • 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 elevator system 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 50 floors · 12 cars · sub-second dispatch decision.
  • 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 50 floors · 12 cars · sub-second dispatch decision. Convert it into peak throughput, retained records, bandwidth, and failure budget; then connect each number to a component.

DimensionWorking estimateDesign implication
Traffic50 floors · 12 cars · sub-second dispatch decisionSeparate 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

CALL(floor, direction)hall request
SELECT(car, destination)cabin request
EVENT(car, position/door/load)hardware event
COMMAND(car, target, mode)dispatcher action

Authoritative records and indexes

car(car_id, floor, direction, door_state, load, mode, version)

request(request_id, floor, direction, assigned_car, state)

stop_plan(car_id, ordered_stops, generation)

fault(car_id, code, observed_at, cleared_by)

Command and event envelopes

# Command envelope
operation: CALL(floor, direction)
request_id: req_01J...
idempotency_key: idem_7f2...
aggregate_key: elevator-system_123
expected_version: 17
payload: {...}

# Durable event
event_id: evt_01J...
aggregate_key: elevator-system_123
event_type: elevator_system_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
Hall PanelOwns client protocol, request identity, retry, and resume behavior. In this design it participates in: Deduplicate hall/cabin requests and snapshot all eligible car states.Separates a distinct scale, ownership, policy, or failure boundary. It prevents the external caller from also owning the contract and failure behavior of Cabin Panel.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 “Car stops reporting position” 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 Hall Panel boundary before extracting or scaling it.
Cabin PanelOwns client protocol, request identity, retry, and resume behavior. In this design it participates in: Dispatch strategy scores direction, distance, load, stops, and service mode.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Hall Panel from also owning the contract and failure behavior of Building 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 “Door obstruction repeats” to Hall Panel.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 Cabin Panel boundary before extracting or scaling it.
Building ControllerOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Assign request by generation; car controller inserts a legal stop into its plan.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Cabin Panel from also owning the contract and failure behavior of Dispatch Strategy.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 “Duplicate hall request survives assignment” to Cabin Panel.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 Building Controller boundary before extracting or scaling it.
Dispatch StrategyOwns one bounded domain decision, transition, or operational capability. In this design it participates in: State machine commands motion only with doors locked and safety interlocks healthy.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Building Controller from also owning the contract and failure behavior of Request Deduper.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 “Emergency overrides normal schedule” to Building 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 Dispatch Strategy boundary before extracting or scaling it.
Request DeduperOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Sensor events advance floor/door states; faults remove car and reassign outstanding requests.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Dispatch Strategy from also owning the contract and failure behavior of Car 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 “Destination-control demand spikes” to Dispatch 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 Request Deduper boundary before extracting or scaling it.
Car ControllerOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Deduplicate hall/cabin requests and snapshot all eligible car states.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Request Deduper from also owning the contract and failure behavior of Car 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 “Car stops reporting position” to Request Deduper.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 Car Controller boundary before extracting or scaling it.
Car State MachineOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Dispatch strategy scores direction, distance, load, stops, and service mode.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Car Controller from also owning the contract and failure behavior of Motion 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 “Door obstruction repeats” to Car 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 Car State Machine boundary before extracting or scaling it.
Motion ControllerOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Assign request by generation; car controller inserts a legal stop into its plan.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Car State Machine from also owning the contract and failure behavior of Door 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 “Duplicate hall request survives assignment” to Car 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 Motion Controller boundary before extracting or scaling it.
Door ControllerOwns one bounded domain decision, transition, or operational capability. In this design it participates in: State machine commands motion only with doors locked and safety interlocks healthy.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Motion Controller from also owning the contract and failure behavior of Floor 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 “Emergency overrides normal schedule” to Motion 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 Door Controller boundary before extracting or scaling it.
Floor SensorsOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Sensor events advance floor/door states; faults remove car and reassign outstanding requests.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Door Controller from also owning the contract and failure behavior of Load Sensor.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 “Destination-control demand spikes” to Door 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 Floor Sensors boundary before extracting or scaling it.
Load SensorOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Deduplicate hall/cabin requests and snapshot all eligible car states.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Floor Sensors from also owning the contract and failure behavior of Safety Interlock.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 “Car stops reporting position” to Floor 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 Load Sensor boundary before extracting or scaling it.
Safety InterlockOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Dispatch strategy scores direction, distance, load, stops, and service mode.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Load Sensor from also owning the contract and failure behavior of Fault Manager.Embed policy in every caller. Rules then drift by deployment version and emergency changes require fleet-wide redeployment. Here that simpler choice would couple “Door obstruction repeats” to Load Sensor.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 Safety Interlock boundary before extracting or scaling it.
Fault ManagerOwns one bounded domain decision, transition, or operational capability. In this design it participates in: Assign request by generation; car controller inserts a legal stop into its plan.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Safety Interlock from also owning the contract and failure behavior of Maintenance Console.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 “Duplicate hall request survives assignment” to Safety Interlock.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 Fault Manager boundary before extracting or scaling it.
Maintenance ConsoleOwns one bounded domain decision, transition, or operational capability. In this design it participates in: State machine commands motion only with doors locked and safety interlocks healthy.Separates a distinct scale, ownership, policy, or failure boundary. It prevents Fault Manager from also owning the contract and failure behavior of operators and repair tooling.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 “Emergency overrides normal schedule” to Fault Manager.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 Maintenance Console boundary before extracting or scaling it.
Decision 01

Chosen boundary vs simpler monolith

Model each car as a state machine with direction, door, position, load, and fault states.

A single deployable with one transactional store is the right starting point for a small elevator system workload. The proposed boundary becomes justified when model each car as a state machine with direction, door, position, load, and fault states. Separating it contains the named failure “Car stops reporting position” without placing unrelated work on the critical path.

Decision 02

Correctness vs availability

Separate dispatch policy from car control; SCAN/LOOK-style scheduling is a baseline, not the only answer.

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

Safety interlocks override optimization: doors, overload, emergency stop, and maintenance modes are authoritative.

This choice adds dashboards, ownership, schema compatibility, capacity planning, and recovery runbooks. Start with the minimum topology that supports “Assign request by generation; car controller inserts a legal stop into its plan.” 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 each car as a state machine with direction, door, position, load, and fault states.

Scale boundary

Separate dispatch policy from car control; SCAN/LOOK-style scheduling is a baseline, not the only answer.

Operational boundary

Safety interlocks override optimization: doors, overload, emergency stop, and maintenance modes are authoritative.

↑ top

5. Critical flow and algorithm

01

Deduplicate hall/cabin requests and snapshot all eligible car states.

02

Dispatch strategy scores direction, distance, load, stops, and service mode.

03

Assign request by generation; car controller inserts a legal stop into its plan.

04

State machine commands motion only with doors locked and safety interlocks healthy.

05

Sensor events advance floor/door states; faults remove car and reassign outstanding requests.

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
Car stops reporting positionStop 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.
Door obstruction repeatsStop 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.
Duplicate hall request survives assignmentResolve at source of truth with uniqueness, expected version, lease generation, or monotonic cursor.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.
Emergency overrides normal scheduleStop 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.
Destination-control demand spikesIsolate the key/tenant/priority, apply admission control, and preserve durable work.Reconciliation returns zero invariant gaps; lag/replica health and user-visible SLO return to baseline.

Recovery checkpoint

# Recovery checkpoint
scenario: Car stops reporting position
operation_id: op_01J...
aggregate_key: elevator-system_123
last_durable_version: 18
projection_checkpoint: partition-07@offset-482901
retry_policy: same_identity / bounded_backoff
reconciliation_status: pending
owner: Maintenance Console

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: Car stops reporting position — 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

How do you handle peak up traffic?

Model each car as a state machine with direction, door, position, load, and fault states. Walk the concrete lifecycle step “Deduplicate hall/cabin requests and snapshot all eligible car states.” Then test it against “Car stops reporting position”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

How are duplicate requests coalesced?

Separate dispatch policy from car control; SCAN/LOOK-style scheduling is a baseline, not the only answer. Walk the concrete lifecycle step “Dispatch strategy scores direction, distance, load, stops, and service mode.” Then test it against “Door obstruction repeats”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

What happens when a car fails?

Safety interlocks override optimization: doors, overload, emergency stop, and maintenance modes are authoritative. Walk the concrete lifecycle step “Assign request by generation; car controller inserts a legal stop into its plan.” Then test it against “Duplicate hall request survives assignment”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

How do destination-control elevators differ?

Model each car as a state machine with direction, door, position, load, and fault states. Walk the concrete lifecycle step “State machine commands motion only with doors locked and safety interlocks healthy.” Then test it against “Emergency overrides normal schedule”. State the retry identity, durable checkpoint, recovery signal, and cost of the alternative.

How do you test safety logic?

Separate dispatch policy from car control; SCAN/LOOK-style scheduling is a baseline, not the only answer. Walk the concrete lifecycle step “Sensor events advance floor/door states; faults remove car and reassign outstanding requests.” Then test it against “Destination-control demand spikes”. 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