Getting Ready: Online Shopping

E-commerce is one of the largest and most complex software domains in existence. Amazon alone processes over 400 million unique products, handles 66,000 orders per hour on average (spiking to 12,000+ per second during Prime Day), and coordinates a multi-stakeholder ecosystem of buyers, sellers, warehouses, payment processors, and delivery partners — all in real time.

But you don't need to be Amazon-scale to face these design challenges. Every online shopping system — from a small Shopify storefront to Walmart.com — must solve the same fundamental object-oriented problems:

• Product catalog management — how do you model products with varying attributes (electronics have specs, clothing has sizes/colors, books have ISBNs)?
• Shopping cart logic — how do you maintain a cart that tracks quantities, handles price changes, and survives user sessions?
• Order lifecycle — an order isn't just "placed" or "delivered." It moves through a state machine: Pending → Confirmed → Shipped → Delivered (or Cancelled, or Returned). Each state has different rules about what can happen next.
• Payment extensibility — credit card today, UPI tomorrow, crypto next year. How do you add new payment methods without rewriting order processing?
• Inventory coordination — when a user adds the last item to their cart, what happens if another user tries to buy it simultaneously?

This is one of the most frequently asked LLD interview questions at companies like Amazon, Flipkart, Walmart Labs, Shopify, and eBay. Interviewers love it because it's rich enough to test class hierarchies, state management, design patterns, and concurrency awareness — all in a single 45-minute session.

Unlike simpler problems (Parking Lot, Tic Tac Toe), Online Shopping introduces multi-entity workflows — a single "Place Order" action touches the Cart, Inventory, Payment, Order, and Notification subsystems. Designing clean boundaries between these subsystems is what separates a junior design from a senior one.

By completing the Online Shopping System design problem, you will:

• Design a multi-entity domain model with 15+ classes spanning Users, Products, Cart, Orders, Payments, and Notifications — your most complex class hierarchy so far
• Apply the State Pattern to model the Order lifecycle (Pending → Confirmed → Shipped → Delivered / Cancelled / Returned) — a real-world state machine with guards and side effects on transitions
• Apply the Strategy Pattern for swappable payment methods — credit card, debit card, UPI, digital wallet — without modifying order processing code
• Apply the Factory Pattern to create different product types with varying attribute sets
• Apply the Observer Pattern to notify customers of order status changes — decoupling the order state machine from notification delivery
• Draw four UML diagram types — Use Case, Class, State Machine, and Sequence diagrams — applying the full UML toolkit from Fundamentals S5
• Implement the complete system in Python and Java — clean, compilable code organized by domain boundaries
• Handle real-world edge cases — out-of-stock during checkout, payment failure rollback, concurrent cart modifications, and order cancellation windows

This problem ties together almost every concept from the Fundamentals section — inheritance, composition, interfaces, SOLID principles, and multiple design patterns working in concert.

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

• Classes, Inheritance, and Polymorphism — you'll design abstract product hierarchies and polymorphic payment processing (Fundamentals S3)
• OOP Relationships — Composition (Order owns OrderItems), Association (User has a ShoppingCart), Aggregation (Cart references Products). Knowing when to use each is critical here (Fundamentals S4)
• UML Diagrams — Class diagrams, State Machine diagrams, Sequence diagrams, and Use Case diagrams. This problem uses all four (Fundamentals S5)
• SOLID Principles — especially OCP (adding new payment methods) and SRP (each class owns one responsibility). You'll see SOLID violations and fixes throughout (Fundamentals S6)
• State Pattern — orders move through states with different allowed transitions. If you haven't studied the State Pattern yet, revisit Fundamentals S12 before the State Machine Diagram tutorial
• Strategy Pattern — payment processing is a textbook Strategy application. Review Fundamentals S12 if needed
• Observer Pattern — order status notifications are decoupled using Observer. Review Fundamentals S12 if needed
• Factory Pattern — product creation uses a Factory to handle different product types. Review Fundamentals S10

You should also have completed at least one easier design problem (DP1-DP7) to be familiar with the full design workflow: Requirements → UML → Code → Patterns.

We will design: The core domain logic of an online shopping system — the classes, their relationships, state management for orders, and the key workflows. This includes:

• User management — Buyer and Seller accounts with authentication state and profiles
• Product catalog — Products with categories, attributes, and inventory tracking
• Shopping cart — Add/remove/update items, calculate totals, clear on checkout
• Order processing — Place an order, track its lifecycle through a state machine (Pending → Confirmed → Shipped → Delivered, with Cancelled and Returned branches)
• Payment handling — Strategy-based payment processing supporting multiple payment methods (Credit Card, Debit Card, UPI, Digital Wallet)
• Order notifications — Observer-based status change notifications to customers
• Inventory management — Stock tracking, decrement on order placement, restore on cancellation

We will NOT design:

• Database schemas or persistence — this is object-oriented design, not data modeling
• REST APIs, GraphQL, or HTTP endpoints — our system lives at the class level
• Recommendation engines or search ranking — these are algorithmic concerns beyond LLD scope
• Distributed systems — no load balancing, caching, CDNs, or microservice boundaries
• Frontend/UI — no web pages, mobile apps, or user interfaces
• Logistics and delivery tracking — we model order states but not the actual delivery routing
• Reviews and ratings — a separate subsystem that would add complexity without teaching new patterns

This boundary is crucial. In an interview, always clarify: "Are we designing the object model and class interactions, or the system architecture?" We stay firmly at the class and object level: which classes exist, how they relate, and how they interact through method calls.

Over the next 9 tutorials, we'll follow a systematic design process — the same process you'd use in a 45-minute LLD interview, expanded for thorough learning:

1. Requirements — Define functional and non-functional requirements, clarify scope boundaries, and establish the contract our system must fulfill
2. Use Case Diagram — Identify actors (Buyer, Seller, System) and their interactions with the shopping system
3. Class Diagram — Design the structural blueprint: 15+ classes across User, Product, Cart, Order, Payment, and Notification domains with all attributes, methods, and relationships
4. State Machine Diagram — Order Lifecycle — Model the complete order state machine: states, transitions, guards, and side effects at each state change
5. Sequence Diagram — Place an Order — Trace the end-to-end message flow when a buyer places an order: cart → inventory check → payment → order creation → notification
6. Code Implementation — Write the complete system in Python and Java, organized by domain boundaries
7. Design Patterns Applied — Analyze the four patterns used (State, Strategy, Observer, Factory), why each was chosen, and what alternatives were rejected
8. Payment Strategy & Extensibility — Deep dive into the Strategy Pattern for payment processing — how to add new payment methods without touching existing code
9. Summary & Key Takeaways — Recap decisions and prepare for interview follow-ups

This is the 4-Step Framework from Fundamentals S16 (Requirements → UML → Code → Patterns), applied to a Hard-level design problem. The challenge isn't just the number of classes — it's keeping the boundaries clean while multiple subsystems interact.

Let's build an online shopping system.