Requirements for the Shopping System

Let's define exactly what our Online Shopping System must do. Each requirement is specific, testable, and will directly drive at least one class or method in our design.

User Management:

1. FR1: The system shall support two types of users — Buyers (who browse, add to cart, place orders) and Sellers (who list products, manage inventory, and view orders for their products). Both share common account attributes (name, email, address) but have distinct capabilities.
2. FR2: A buyer shall have a shipping address and a shopping cart that persists across the session. A seller shall have a store name and a list of products they sell.

Product Catalog:

3. FR3: The system shall support a product catalog where each product has a name, description, price, category, and available stock quantity. Products belong to exactly one seller.
4. FR4: Products shall be organized into categories (e.g., Electronics, Clothing, Books, Home & Kitchen). A product belongs to exactly one category, and a category can contain many products.
5. FR5: The system shall allow searching products by name or category. The search returns a list of matching products with their current availability.

Shopping Cart:

6. FR6: A buyer shall be able to add products to their cart with a specified quantity. If the product is already in the cart, the quantity shall be updated (not duplicated).
7. FR7: A buyer shall be able to remove items from the cart or update the quantity of an existing cart item.
8. FR8: The cart shall calculate the total price by summing (price × quantity) for all items. This total is recalculated whenever items are added, removed, or updated.
9. FR9: The cart shall be clearable — emptied entirely after a successful order placement or by explicit user action.

Order Processing:

10. FR10: A buyer shall be able to place an order from their cart. Placing an order creates an Order object containing all cart items, the total amount, a shipping address, and the selected payment method.
11. FR11: On order placement, the system shall verify inventory — if any item's requested quantity exceeds available stock, the order shall be rejected with an out-of-stock error.
12. FR12: On successful inventory verification, the system shall decrement stock for each ordered product by the ordered quantity.
13. FR13: Each order shall have a unique order ID and a creation timestamp.

Order Lifecycle (State Machine):

14. FR14: An order shall progress through a defined state machine: PENDING → CONFIRMED → SHIPPED → DELIVERED. Each transition is triggered by a specific action.
15. FR15: An order in PENDING or CONFIRMED state shall be cancellable. Cancellation moves the order to CANCELLED state and restores inventory for all items.
16. FR16: An order in DELIVERED state shall be returnable within the return window. A return moves the order to RETURNED state and restores inventory.
17. FR17: State transitions shall be validated — e.g., a SHIPPED order cannot be directly cancelled (it must be delivered first, then returned), and a CANCELLED order cannot be shipped.

Payment:

18. FR18: The system shall support multiple payment methods: Credit Card, Debit Card, UPI, and Digital Wallet. Each method processes payments differently.
19. FR19: Payment shall be processed during order placement. If payment fails, the order is not created and inventory is not decremented.
20. FR20: Adding a new payment method in the future shall not require modifying existing order processing or other payment method code (Open/Closed Principle).

Notifications:

21. FR21: When an order's state changes (confirmed, shipped, delivered, cancelled, returned), the buyer shall be notified with the order ID and new status.
22. FR22: Notifications shall be decoupled from order state management — the order state machine should not know or care how notifications are delivered (email, SMS, push).

Beyond functionality, our design must meet these quality requirements:

1. Extensibility (OCP): Adding a new payment method (e.g., Cryptocurrency) should require creating a new class that implements the PaymentStrategy interface — zero changes to existing code. Similarly, adding a new order state (e.g., PROCESSING) should only require adding one new state class.

2. Single Responsibility (SRP): Each class owns exactly one reason to change. The Order class manages order data and state transitions — not payment processing, not inventory management, not notifications. Each concern lives in its own class.

3. Testability: Each component must be testable in isolation. The ShoppingCart can be tested without a database. The Order state machine can be tested without a payment gateway. Payment strategies can be tested without real payment processor connections.

4. Thread Safety Awareness: While we won't implement full concurrency control, our design should acknowledge concurrent access points — two buyers adding the last item to their carts simultaneously, or simultaneous order placement depleting inventory. We'll identify where synchronization would be needed in a production system.

5. Clean Separation of Concerns: The system should be organized into clear domain boundaries:

   • User domain — account management, roles
   • Product domain — catalog, categories, inventory
   • Cart domain — session-based item collection
   • Order domain — lifecycle management, state transitions
   • Payment domain — strategy-based payment processing
   • Notification domain — observer-based status updates

In Scope:

• User hierarchy (Buyer, Seller) with role-specific attributes and behavior
• Product catalog with categories and stock management
• Shopping cart with add/remove/update/clear operations and total calculation
• Order creation from cart with inventory verification
• Order state machine (Pending → Confirmed → Shipped → Delivered, with Cancelled and Returned branches)
• Strategy-based payment processing with 4 payment methods
• Observer-based order status notifications
• Inventory decrement on order and restore on cancellation/return

Out of Scope:

• Pricing variations — coupons, discounts, taxes, shipping fees (adds complexity without teaching new patterns)
• Product reviews and ratings — a separate subsystem entirely
• Recommendation engine — algorithmic, not OOP design
• Wishlist — similar pattern to cart, doesn't add new design value
• Multi-seller orders — splitting an order across sellers adds orchestration complexity beyond LLD scope
• Delivery logistics — route planning, driver assignment (this is a system design concern)
• Database/persistence — we model in-memory objects, not database schemas
• REST APIs — we design classes and methods, not HTTP endpoints
• Authentication/authorization — we assume users are authenticated at the system boundary

Every requirement above will map to concrete design elements. Here's a preview of how requirements drive the design:

Requirement	Design Element
FR1-FR2 (User types)	User abstract class → Buyer, Seller subclasses
FR3-FR5 (Products)	Product class, ProductCategory enum, ProductCatalog service
FR6-FR9 (Cart)	ShoppingCart class, CartItem class
FR10-FR13 (Order creation)	Order class, OrderItem class, OrderService
FR14-FR17 (State machine)	OrderStatus enum, State Pattern classes
FR18-FR20 (Payment)	PaymentStrategy interface → CreditCardPayment, DebitCardPayment, UPIPayment, WalletPayment
FR21-FR22 (Notifications)	OrderObserver interface, NotificationService

This traceability ensures no class exists without justification and no requirement is left unimplemented. We'll reference these requirement numbers (FR1, FR2, etc.) throughout the remaining tutorials.

In a real interview, spend 5-7 minutes clarifying requirements before designing. This problem is complex enough that scope ambiguity will derail you. Ask questions like:

• "Are we modeling a marketplace (multiple sellers) or a single-store system?" — This dramatically changes the class hierarchy.
• "Should the order support partial fulfillment (some items shipped, some backordered)?" — If yes, you need OrderItem-level state management.
• "Is real-time inventory checking in scope, or do we just track stock counts?" — Real-time implies concurrency concerns.
• "Do we need to handle payment refunds on cancellation, or just restore inventory?" — Refund processing adds another strategy layer.
• "How many payment methods should the design support initially?" — This tells you whether Strategy Pattern is justified (2+ methods = yes).

Interviewers expect you to narrow the scope for a 45-minute session. Our design above is comprehensive for learning purposes, but in an interview, you might say: "Let me focus on the Order lifecycle and Payment strategy, and sketch the Cart and Product classes at a high level." Prioritize depth over breadth.