Amazon·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

System design round at Amazon for an embedded software role, which felt a bit odd given the locker problem was pretty classic backend territory. The question had enough moving parts to keep me busy the whole session.

Questions Asked (1)

Design a storage locker system that can store and retrieve items across multiple locker sizes (small, medium, large). The system should assign the smallest available locker that fits a given item, and return an error if no suitable locker exists. Cover the data model, store/retrieve APIs, allocation strategy, concurrency handling, and how you'd scale it.

System DesignData ModelingTechnical Trade-offs

Author's notes

I started with the data model and that went fine, basically a locker table with size enum, status, and a foreign key to whatever item is currently stored.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then design a data model that tracks lockers and their availability. Focus on the core allocation algorithm using a size-ordered data structure, and address concurrency and scalability with locking and sharding. Finally, discuss trade-offs and potential optimizations.

Pro tip: Emphasize the importance of idempotency and atomicity in store/retrieve operations, and how you would handle failures gracefully. Mention that you'd start with a simple solution and iterate based on metrics like locker utilization and contention.

1. Clarify Requirements and Constraints

Ask questions to understand expected scale, locker sizes, item dimensions, retrieval patterns, and consistency requirements. Define functional and non-functional requirements.

2. Design Data Model and APIs

Define entities like Locker, Item, and Assignment. Specify store(item) and retrieve(itemId) APIs, including error cases. Consider using a database schema with indexes on size and availability.

3. Develop Allocation Strategy

Explain how to assign the smallest available locker that fits. Use a size-ordered data structure (e.g., balanced tree or priority queue) per size category, and check availability in ascending size order.

4. Address Concurrency and Consistency

Discuss locking mechanisms (e.g., per-locker locks, optimistic concurrency) to prevent double allocation. Ensure atomic operations for store/retrieve, and handle failures with retries or transactions.

5. Plan for Scalability and Trade-offs

Propose scaling strategies like sharding by location or locker ID, caching availability, and using distributed locks. Discuss trade-offs between consistency and availability, and potential bottlenecks.

Key Points to Mention

Data model: Locker (id, size, location, status), Item (id, size, dimensions), Assignment (lockerId, itemId, timestamp).
Allocation algorithm: maintain separate queues or trees for each size; on store, check small, then medium, then large; if none, return error.
Concurrency: use database transactions with SELECT FOR UPDATE or distributed locks (e.g., Redis) to prevent race conditions.
Scalability: shard by geographic region or locker bank; use consistent hashing for locker assignment; consider eventual consistency for availability counts.
Error handling: define specific errors for no locker available, invalid item size, and locker already occupied.
Trade-offs: simplicity vs. scalability, strong vs. eventual consistency, and cost of locking vs. performance.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.