Design an Amazon Locker Service
AmazonSoftware Engineer · Technical ScreenLast updated
Tests object-oriented design and state-machine modeling for a self-service package locker station, focusing on parcel allocation, code expiration, and physical-vs-logical state consistency.
Scenario
Design the core software architecture and domain model for an automated self-service package locker station (e.g., Amazon Hub Locker). The kiosk contains a fixed set of physical compartments of varying sizes and serves both couriers, customers, and return/maintenance staff.
Requirements
Functional Requirements
- Compartment Allocation: The station contains compartments in fixed sizes (
SMALL,MEDIUM,LARGE,EXTRA_LARGE). When a package arrives, assign it to the smallest available compartment that fits the package dimensions. - Customer Pickup Code: Depositing a package generates a secure, one-time pickup code valid for exactly 7 days.
- Customer Pickup Workflow: Entering a valid, unexpired code unlocks the corresponding compartment door. When the door is closed, the pickup is completed and the compartment becomes available.
- Expiration Workflow: If 7 days elapse without pickup, the access code expires. The parcel state transitions to expired, but the compartment must not be marked available for new deposits until the package is physically removed.
- Staff Clearance: Station staff must be able to view and unlock expired compartments, physically extract the package, and explicitly submit a removal confirmation to release the compartment back to the available pool.
Non-Functional Requirements
- State Integrity: A pickup code expiring or being invalidated must never prematurely release a compartment while an item remains inside.
- Concurrency: Prevent race conditions where two couriers attempt to allocate the same physical compartment simultaneously.
What to Cover
- Class Design & Domain Entities: Define key classes (e.g.,
LockerStation,Compartment,Package,AccessTicket,StaffService). - State Modeling: Define clear state transitions for both
Compartment(e.g.,AVAILABLE,RESERVED,OCCUPIED,PENDING_CLEARANCE) andPackage(e.g.,DEPOSITED,RETRIEVED,EXPIRED,RETURNED_TO_DEPOT). - API & Workflow Methods: Provide class signatures and step-by-step logic for:
allocateAndDeposit(packageDetails)pickup(code)expireTicket(ticketId)clearExpiredCompartment(staffId, compartmentId)
- Edge Cases: Handle sensor failures (e.g., door opened but closed without package removal) and code expiration while customer is in front of the kiosk.
Hints
Hint 1
Decouple the lifecycle state of the physical compartment from the logical state of the customer's access ticket.
Hint 2
Model explicit state transitions for the compartment so that an expired ticket leaves the locker in a pending clearance state rather than directly returning to available.
Hint 3
Consider what physical sensors (door latch sensors, internal optical/weight sensors) exist and how software verifies that a compartment is truly empty before reallocating it.
Follow-up questions
- How would you handle a scenario where a customer accidentally shuts the compartment door before taking their package?
- How should the local locker kiosk sync state with the cloud backend during a temporary Internet outage?
- If physical weight or optical sensors are unavailable, how can the software guarantee a compartment is truly empty before assigning it to a new delivery?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.