Amazon Lock (OOD)

Amazon Lock (OOD) Overview
The "Amazon Lock" or "Amazon Locker" problem is a common Object-Oriented Design (OOD) interview question at Amazon, focusing on designing a locker system for package delivery and pickup. It tests skills in backend system design, OOD principles, web integration, and sometimes machine learning for optimization like locker selection. The core scenario involves drivers depositing packages into automated lockers and customers retrieving them via access codes.[1][3]

Full Problem Statement

Customers order items on Amazon and opt for locker delivery at nearby locations (e.g., stores or malls). Delivery personnel deposit packages into available compartments of appropriate sizes (small, medium, large). The system generates a unique access token (e.g., 6-digit code) sent to the customer via email/SMS, valid for a limited period (typically 3-7 days). Customers enter the code at the locker to open the compartment and retrieve the package.

Key requirements:

• Find an optimal available compartment based on package size.
• Generate and validate expiring access tokens.
• Handle edge cases like no space available, invalid/expired codes, or staff intervention for abandoned packages.
• Support returns (customer deposits returned items).
• Lockers operate within store hours; expired items trigger refunds or staff removal.

Out of scope: Delivery logistics, payment, UI rendering, multiple locker networks.[3][7][1]

Input/Output Examples

From typical implementations (e.g., Java/C++ class designs):

Deposit Package:
Input: locker.depositPackage(PackageSize.MEDIUM) Logic: Finds free medium compartment (e.g., "B"), opens it automatically, generates token "ABC123" (expires in 7 days), marks occupied. Output: "ABC123" (token for customer notification) State change: Compartment B occupied, token mapped to B.[1]

Pickup Package:
Input: locker.pickupPackage("ABC123") Logic: Validates token (exists, not expired), opens compartment B, marks free, removes token mapping. Output: void (door opens physically; errors thrown if invalid/expired: "Access token expired" or "Invalid code"). Failed case (expired): Throws error, compartment stays locked/occupied.[1]

Staff Clear Expired:
Input: locker.clearAllExpired() Logic: Opens all compartments with expired tokens for manual package removal/return to sender. Output: void (multiple doors open).

Constraints

• Compartments: Fixed per locker (e.g., 3-10: mix of small/medium/large). Each has size, occupied status, and hardware lock.
• Sizes: Enum (SMALL ≤ MEDIUM ≤ LARGE); must fit exact or larger.
• Tokens: Unique alphanumeric, 7-day expiry (or 3 days in some variants), one-time use.
• Capacity: No space → reject deposit (throw error or suggest alternative locker).
• Concurrency: Thread-safe (multiple drivers/customers); use locks/synchronization.
• Scalability: Single locker station (no multi-location); no lockout on failed attempts.
• Edge Cases: Invalid size, null/empty token, already-used token, hardware failure simulation.
  No hard performance metrics, but O(1) ideal for lookups via HashMap<token, AccessToken>.[3][1]

Design Highlights

Core classes: Locker, Compartment, AccessToken, PackageSize.

• Locker manages compartment array and token map.
• Methods focus on deposit/pickup with validation.
  This matches Amazon's backend/OOD interviews for SDE roles, emphasizing clean encapsulation and error handling.[9][1]