What Candidates Reported
A Glassdoor question attached to an Amazon Software Engineer interview asks for the Locker service from drop-off and pickup through slot assignment. A separate candidate who received an Amazon L5 offer lists Amazon Locker as the HLD round and distinguishes it from a parking-lot LLD round. Together, these reports support practising Locker as a full distributed-system problem.
Problem and Scope
Design locker discovery, compartment reservation, courier deposit, customer pickup, expiry, and capacity release. Establish who owns each transition, how package size constrains assignment, what users see when capacity is stale, and how support resolves exceptions before choosing storage or messaging technology.
Critical Design Decisions
The central distinction is between approximate discovery and authoritative allocation. Strong designs use explicit package and compartment state machines, conditional ownership changes, idempotency keys, expiring holds, and durable custody events. The locker controller also needs a defined offline authority and reconciliation protocol because physical door state cannot be inferred safely from a lost network response.
Failure Scenarios to Practise
Pressure-test concurrent requests for the final compartment, a lost allocation response, an offline controller during drop-off, expired pickup credentials, a full city during peak demand, and disagreement between physical sensors and backend state. For every case, state whether the compartment is available, who may act, and how the system recovers without losing custody.
How the Answer Is Evaluated
MockMe scores scope and workflows (15%), state and allocation correctness (30%), architecture and scale (20%), devices, security, and recovery (20%), and communication and trade-offs (15%). The strongest answers treat custody and compartment ownership as explicit correctness problems rather than incidental database rows.