Amazon Locker System Design Explained
Learn how Amazon Locker balances security, capacity, and physical constraints. This deep dive breaks down locker reservation, pickup codes, expiration handling, and scalable last-mile delivery design.
Amazon Locker feels like a small convenience feature. Instead of waiting at home for a delivery, you choose a locker near you, receive a code, and pick up your package whenever it suits you. Simple, quick, and reliable.
But from a System Design perspective, Amazon Locker represents a deceptively complex problem. It blends e-commerce order fulfillment with physical infrastructure, constrained resources, secure access control, and real-world failure handling. Unlike standard doorstep delivery, Amazon Locker introduces capacity limits, location binding, time windows, and physical state management.
That’s why Amazon Locker System Design is a strong System Design interview topic. It tests whether you can design systems that coordinate digital workflows with physical constraints while maintaining security, scalability, and user trust. In this blog, we’ll walk through how an Amazon Locker–like system can be designed, focusing on architecture, trade-offs, and operational realities rather than abstract theory.
Grokking Modern System Design Interview
System Design Interviews decide your level and compensation at top tech companies. To succeed, you must design scalable systems, justify trade-offs, and explain decisions under time pressure. Most candidates struggle because they lack a repeatable method. Built by FAANG engineers, this is the definitive System Design Interview course. You will master distributed systems building blocks: databases, caches, load balancers, messaging, microservices, sharding, replication, and consistency, and learn the patterns behind web-scale architectures. Using the RESHADED framework, you will translate open-ended system design problems into precise requirements, explicit constraints, and success metrics, then design modular, reliable solutions. Full Mock Interview practice builds fluency and timing. By the end, you will discuss architectures with Staff-level clarity, tackle unseen questions with confidence, and stand out in System Design Interviews at leading companies.
Understanding the Core Problem#
At its core, Amazon Locker is a last-mile delivery alternative that replaces home delivery with secure, self-service pickup locations. Each locker location consists of a finite number of compartments of varying sizes, each of which can hold exactly one package at a time.
This introduces a fundamentally different constraint model compared to traditional delivery. Packages can’t simply be dropped off whenever a driver arrives. They must be assigned to a locker, fit in an available compartment, and be picked up within a limited time window before space is reclaimed.
The system must continuously answer several critical questions. Is there a locker available near the customer? Will a compartment of the right size be available at delivery time? Has the package been picked up? What happens if it isn’t?
These questions tie together order management, inventory-like capacity tracking, secure access, and time-based workflows.
Core Functional Requirements#
To ground the design, we start with what the system must do.
From a customer’s perspective, Amazon Locker must allow users to select a locker location during checkout, receive a pickup code, and retrieve their package securely. From Amazon’s perspective, the system must manage locker availability, guide delivery drivers, and handle uncollected packages safely.
More concretely, the system must support:
Locker discovery and selection during checkout
Reservation of locker capacity
Secure package drop-off by delivery personnel
Time-bound pickup by customers
Automated handling of expired pickups
What makes this system interesting is that lockers behave like shared, constrained resources, similar to seats on a flight or rooms in a hotel, but with physical hardware involved.
Scalability & System Design for Developers
As you progress in your career as a developer, you'll be increasingly expected to think about software architecture. Can you design systems and make trade-offs at scale? Developing that skill is a great way to set yourself apart from the pack. In this Skill Path, you'll cover everything you need to know to design scalable systems for enterprise-level software.
Non-Functional Requirements That Shape the Design#
Amazon Locker System Design is heavily driven by non-functional requirements.
Security is paramount. Locker access codes must be unguessable and time-limited. Availability must be accurate, because sending a package to a full locker creates costly recovery workflows. Reliability matters because lockers are often unattended.
Scalability is also important. Amazon operates lockers globally, across cities with very different usage patterns. The system must scale without centralized bottlenecks and must isolate failures at individual locations.
Latency is less critical than correctness and predictability. Customers are willing to wait an extra second during checkout if it guarantees a smooth pickup experience later.
Non-functional requirements and design impact#
Requirement | Why it matters | Design implication |
Security | Prevent unauthorized access | Cryptographic, time-limited codes |
Availability accuracy | Avoid failed deliveries | Conservative reservations |
Reliability | Unattended physical systems | Hardware fault tolerance |
Scalability | Global locker network | Regional isolation |
Predictability | Customer trust | Correctness over latency |
High-Level Architecture Overview#
At a high level, Amazon Locker can be decomposed into several major subsystems:
A locker discovery and reservation service
A locker capacity and state management system
An order-to-locker assignment workflow
A secure access and code generation service
A delivery driver interaction system
A pickup and expiration handling service
Each subsystem deals with different types of state: digital orders, physical compartments, time-based reservations, and security credentials. Keeping these concerns separated is essential for correctness and scalability.
Locker Discovery and Selection#
The customer journey begins during checkout.
When a user selects Amazon Locker delivery, the system must show nearby locker locations that are eligible for the order. Eligibility depends on multiple factors, including locker proximity, operating hours, and the availability of compartments large enough for the package.
This is a read-heavy operation optimized through caching and precomputation. Locker metadata changes infrequently, but availability fluctuates throughout the day. The system often shows best-effort availability, with final confirmation happening later in the flow.
The key is to avoid overpromising. It’s better to hide a locker that might become available than to allow selection and fail later.
Capacity Reservation and Package Assignment#
Once a locker is selected, the system must reserve capacity.
This is one of the hardest parts of Amazon Locker System Design. The system must predict whether a suitable compartment will be available at the time of delivery, not just at checkout. Deliveries happen hours or days later, and the locker state may change in the meantime.
Constraints:
Capacity reservations must be time-bound
Reservations must account for package size
Overbooking must be aggressively avoided
This often leads to conservative reservation strategies. The system may reserve capacity earlier than strictly necessary or reduce acceptance rates during peak periods to preserve reliability.
Delivery Driver Interaction and Drop-Off#
When the delivery driver arrives at the locker location, the system enters a real-time interaction phase.
The driver authenticates with the locker system, which then assigns a specific compartment. The compartment opens automatically, the package is placed inside, and the locker updates its internal state.
This interaction must be fast and reliable. Drivers cannot afford long delays, and failures here directly impact delivery efficiency. The system must handle cases where hardware malfunctions or compartments fail to open.
If a drop-off fails, fallback workflows route the package to alternative delivery paths or customer service interventions.
Driver drop-off flow states#
Step | Action | Failure handling |
Authenticate | Verify driver identity | Retry / manual override |
Assign compartment | Select reserved slot | Reassign if possible |
Open compartment | Hardware interaction | Fallback routing |
Confirm placement | State update | Reconciliation later |
Locker State Management#
Each locker location maintains a detailed internal state.
Compartments transition through states such as available, reserved, occupied, and expired. These transitions must be tracked accurately and synchronized with backend systems.
Locker state updates originate from both software events and physical hardware signals. Because hardware can fail or go offline, the system must tolerate temporary inconsistencies and reconcile state periodically.
The design favors eventual consistency with strong reconciliation rather than strict real-time guarantees, because physical systems are inherently imperfect.
Secure Access and Pickup Codes#
Security is a defining aspect of Amazon Locker System Design.
Once a package is placed in a locker, the system generates a pickup code or QR token for the customer. This credential must be unique, time-limited, and bound to the specific compartment.
Requirements:
Pickup codes must be cryptographically secure
Codes must expire after pickup or timeout
Access attempts must be logged
When a customer arrives, they authenticate at the locker interface, enter the code, and the correct compartment opens. No human intervention is required, which makes security correctness essential.
Pickup Windows and Expiration Handling#
Locker pickups are time-bound.
Customers typically have a limited window, often a few days, to collect their package. If the package is not picked up within this window, the system must reclaim the compartment.
Expiration handling involves notifying the customer, updating the order state, and scheduling package retrieval. This workflow must be automated and reliable, because expired packages directly block capacity for other customers.
This time-based lifecycle management is similar to TTL handling in distributed systems, but with physical consequences.
Failure Handling and Edge Cases#
Failures are inevitable in a system like this.
Lockers may lose power. Network connectivity may drop. Customers may forget pickup codes. Drivers may attempt drop-offs at incorrect times.
Amazon Locker System Design assumes these failures and provides clear fallback paths. Customer support tools, manual overrides, and recovery workflows are essential components of the system, even if they’re not part of the happy path.
Designing these flows explicitly demonstrates production-level thinking.
Scaling Across Cities and Regions#
Amazon Locker deployments vary widely by region.
Urban areas may have high demand and frequent turnover. Suburban or rural lockers may see infrequent usage but longer pickup windows. The system must adapt to these patterns without global coupling.
This is achieved by scoping locker state and capacity management locally while using shared global services for order integration and security.
Regional isolation ensures that failures or congestion at one locker location do not impact others.
Regional usage patterns#
Region type | Demand pattern | Design adjustment |
Dense urban | High turnover | Aggressive reservation |
Suburban | Moderate usage | Balanced windows |
Rural | Low usage | Longer pickup TTL |
Transit hubs | Burst traffic | Local buffering |
Data Accuracy and Customer Trust#
Trust is central to Amazon Locker.
Customers trust that their package will be there when they arrive. Drivers trust that lockers will open when instructed. Amazon trusts that capacity data reflects reality.
To preserve this trust, the system favors conservative decisions, clear communication, and predictable behavior. It’s better to reject a locker delivery upfront than to fail at pickup time.
How Interviewers Evaluate Amazon Locker System Design#
Interviewers use Amazon Locker to assess your ability to design systems that bridge software and physical infrastructure.
They look for strong reasoning around capacity management, time-based workflows, security, and failure recovery. They care less about low-level APIs and more about how you reason through constraints.
Clear articulation of trade-offs, especially around reservation accuracy versus utilization, is often the strongest signal.
Final Thoughts#
Amazon Locker System Design shows that not all complex systems are about scale alone. Many are about coordination, constraints, and trust.
A strong design emphasizes conservative capacity management, secure access control, resilient state handling, and clear lifecycle ownership. If you can clearly explain how a package moves from checkout to locker to pickup, and how the system behaves when something goes wrong, you demonstrate the system-level judgment required for real-world infrastructure.
