Getting Ready: Online Auction

Online auctions are one of the internet's oldest and most enduring business models. eBay processes over $70 billion in gross merchandise volume annually, and the auction model powers everything from art sales at Christie's and Sotheby's to government spectrum auctions worth billions of dollars. Beyond e-commerce, auction mechanics appear in real-time advertising (Google AdWords runs a second-price auction billions of times per day), domain name sales, and even carbon credit trading.

The core engineering challenge is managing concurrent, time-sensitive state transitions under strict correctness constraints. An auction isn't just a list of bids — it's a stateful entity that transitions through a well-defined lifecycle (Draft, Active, Closed, Settled), where invalid transitions must be impossible and every bid must be validated against the current auction state, timing, and price rules. A single bug that allows a bid after closing or permits a seller to bid on their own item can cause financial disputes and legal liability.

What makes this problem particularly rich for LLD interviews is the intersection of three distinct design patterns. The State Pattern governs the auction lifecycle — what operations are legal in each state and how transitions occur. The Strategy Pattern handles auction format diversity — English (ascending), Dutch (descending), and Sealed-Bid auctions each have fundamentally different bid acceptance and winner determination logic. The Observer Pattern drives the notification system — bidders need real-time updates when they're outbid, when an auction they're watching is about to close, and when they've won. Interviewers love this problem because it naturally requires all three behavioral patterns working together in a single domain, making it a strong test of a candidate's ability to compose patterns rather than apply them in isolation.

• State Pattern — model the auction lifecycle as a finite state machine where each state controls which operations are permitted and how transitions occur
• Strategy Pattern — encapsulate English, Dutch, and Sealed-Bid auction mechanics as interchangeable algorithms behind a common interface
• Observer Pattern — implement a notification system that alerts bidders on outbid events, auction closing, and auction results
• Timer-based auto-close — design the mechanism that automatically transitions an auction from Active to Closed when its end time arrives
• Bid validation — enforce complex rules: minimum increment, reserve price, auction state, bidder eligibility
• UML Class Diagram — design 12-15 classes with state, strategy, and observer relationships
• UML State Machine Diagram — model all auction states and transitions with guards and triggers
• UML Sequence Diagram — trace the message flow when a bidder places a bid in an active English auction
• Three auction format implementations — compare English, Dutch, and Sealed-Bid with code and correctness analysis

Before starting this problem, make sure you're comfortable with:

• State Pattern — how objects change behavior based on internal state, and how transitions are managed (Fundamentals S12). This is the backbone of the auction lifecycle.
• Strategy Pattern — how to encapsulate interchangeable algorithms behind a common interface (Fundamentals S12). Each auction type is a separate strategy.
• Observer Pattern — how to notify dependent objects when state changes (Fundamentals S12). Bidder notifications rely on this.
• OOP Relationships — Composition, Association, and Inheritance. The auction system has rich relationships between auctions, bids, users, and strategies (Fundamentals S4).
• UML Class, State Machine, and Sequence Diagrams — you'll create all three diagram types in this problem (Fundamentals S5).
• Enums and type safety — auction states and categories are modeled as enums for compile-time safety.

If you've completed the Vending Machine (DP6) which uses the State Pattern, and the Elevator System (DP8) which uses both State and Strategy, you're well-prepared. This problem extends those concepts into a domain where time-based transitions and multiple auction formats add significant complexity.

We will design: The core auction domain logic — auction lifecycle management, bid validation and processing, multiple auction format strategies (English, Dutch, Sealed-Bid), winner determination, and bidder notification system. This includes the complete class hierarchy, state machine, and working implementations in Python and Java.

We will NOT design: Payment processing infrastructure, image/media upload for auction items, search and recommendation engines, fraud detection systems, user authentication, REST API endpoints, database schemas, or distributed system concerns like geo-replication. This is a Low Level Design exercise focused on the object-oriented domain model, not a System Design (infrastructure) problem.

What makes this a Hard problem: Unlike simpler state-based designs (Vending Machine, Traffic Signal), the auction system combines state management with time-based triggers, concurrent bid validation, and three distinct auction format strategies — each with different winner-determination logic. The State and Strategy patterns must interoperate cleanly, and the Observer pattern adds a third dimension of complexity.