Requirements for the Auction System

Let's define what our Online Auction System needs to do. Each requirement is specific enough to drive at least one class, method, or state transition in our final design.

1. R1 — User Registration: The system shall allow users to register with a unique user ID, name, email, and contact information. A registered user can act as both a seller (creating auctions) and a bidder (placing bids).

2. R2 — Create Auction: A seller can create an auction by specifying an item (title, description, category), a starting price, an optional reserve price (minimum acceptable sale price), a minimum bid increment, a start time, and an end time. The auction is created in DRAFT state.

3. R3 — Auction Types: The system shall support three auction formats: English auction (ascending price — highest bidder wins), Dutch auction (descending price — first bidder to accept wins), and Sealed-Bid auction (single hidden bid per bidder — highest bidder wins). The auction type is set at creation and cannot change.

4. R4 — Publish Auction: A seller can publish a DRAFT auction, scheduling it for automatic activation at the specified start time. A scheduled auction transitions to ACTIVE when its start time arrives.

5. R5 — Place Bid (English): In an English auction, a bidder can place a bid that must be at least the current highest bid plus the minimum increment. If no bids exist, the bid must meet or exceed the starting price. A bidder cannot bid on their own auction.

6. R6 — Accept Price (Dutch): In a Dutch auction, the price starts high and decreases at configured intervals. The first bidder to accept the current price wins immediately, and the auction closes. If the price drops to a floor (starting price) with no takers, the auction closes unsold.

7. R7 — Submit Sealed Bid: In a Sealed-Bid auction, each bidder submits exactly one bid without seeing others' bids. When the auction closes, the highest bid wins. A bidder cannot modify or retract their sealed bid once submitted.

8. R8 — Auto-Close: The system shall automatically close an English or Sealed-Bid auction when the end time is reached. Upon closing, the system determines the winner (if any) based on the auction type's rules.

9. R9 — Reserve Price Enforcement: If the highest bid at auction close does not meet or exceed the reserve price, the item is marked as unsold (no winner), regardless of the number of bids received. Bidders are not informed of the reserve price.

10. R10 — Winner Determination: Upon closing, the system shall determine the winner based on the auction type: highest bidder for English and Sealed-Bid, first acceptor for Dutch. The winning bid amount becomes the sale price.

11. R11 — Notification System: The system shall notify relevant users on key events: a bidder is outbid (English), an auction they're watching is about to close, an auction result is determined (won/lost/unsold), and a seller's auction receives its first bid.

12. R12 — Bid History: Users can view the complete, chronological bid history of an English auction. For Sealed-Bid auctions, bid history is hidden until the auction closes. The seller can view the number of bids received but not individual bid amounts until close.

13. R13 — Cancel Auction: A seller can cancel an auction only if it is in DRAFT or SCHEDULED state, or in ACTIVE state with zero bids (English/Sealed-Bid). A Dutch auction in ACTIVE state cannot be cancelled. Cancellation transitions the auction to CANCELLED state.

Beyond functionality, our design must satisfy:

1. Bid Ordering Correctness: In English auctions, the system must guarantee that no two bids with the same amount are accepted — the first valid bid at a given price level wins priority. This is critical for fairness and dispute resolution.

2. Extensibility (Open/Closed Principle): Adding a new auction format (e.g., Vickrey second-price, combinatorial auction) must not require modifying existing auction logic. The Strategy Pattern makes this possible — new strategies plug in without touching the core auction flow.

3. State Safety: Invalid state transitions must be impossible at the code level. An ACTIVE auction cannot transition to DRAFT. A CLOSED auction cannot accept new bids. The State Pattern enforces this by delegating actions to state-specific objects.

4. Notification Decoupling: The auction core logic must not depend on how notifications are delivered. Adding a new notification channel (email, SMS, push) must not change the Auction or Bid classes. The Observer Pattern ensures this separation.

5. Testability: Each component — bid validation, state transitions, winner determination, auction strategies — must be testable in isolation without needing the full system running.

In Scope:

• User registration and role management (seller/bidder)
• Auction creation with configurable type, pricing, and scheduling
• Three auction formats: English, Dutch, Sealed-Bid
• Bid validation and processing per auction type
• Auction lifecycle state machine (Draft, Scheduled, Active, Closed, Cancelled, Settled, Unsold)
• Timer-based auto-close mechanism
• Reserve price enforcement
• Winner determination per auction type
• Observer-based notification system for bid events
• Bid history and auction result viewing

Out of Scope:

• Payment processing and escrow (financial infrastructure)
• Item shipping and logistics tracking (fulfillment domain)
• Image upload and media storage for auction items (media infrastructure)
• Search, browse, and recommendation engine (discovery layer)
• Fraud detection and bid shill detection (security/ML domain)
• User authentication and session management (security infrastructure)
• REST API endpoints and database persistence (infrastructure layer)
• Real-time WebSocket connections for live bid updates (transport layer)

We're designing the domain model — the classes and relationships that power the auction business logic. The API layer, database, and real-time communication would wrap around this model but aren't part of the LLD exercise.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Which auction types should we support — just English, or also Dutch and Sealed-Bid?" — This reveals scope and tests whether you know that different formats require fundamentally different logic.
• "Should we support a reserve price?" — This shows awareness of real auction mechanics. Reserve prices affect winner determination.
• "What happens if a bid arrives exactly at auction close time?" — This probes edge case thinking around time-sensitive operations.
• "Can a bidder retract a bid in an English auction?" — In real systems like eBay, retraction is allowed under specific conditions. This shows domain awareness.
• "Is proxy bidding (auto-bidding up to a maximum) in scope?" — This tells the interviewer you understand advanced auction features and are scoping deliberately.
• "How should the system handle a Dutch auction where the price drops to zero with no takers?" — This tests your understanding of Dutch auction termination conditions.

These questions demonstrate that you understand auction mechanics deeply and aren't just designing a "put items up for sale" system.