Applying SOLID to real code in LLD - System Design Exercise

Design: Modular Online Bookstore

Focus on backend code design applying SOLID principles. UI and database implementation details are out of scope.

Functional Requirements

FR1: Users can browse books by category and search by title or author

FR2: Users can add books to a shopping cart and place orders

FR3: Admin can add, update, or remove books

FR4: System should allow easy addition of new payment methods without changing existing code

FR5: System should support multiple types of notifications (email, SMS) for order status updates

Non-Functional Requirements

NFR1: Codebase must be easy to maintain and extend

NFR2: Changes to one feature should not affect unrelated features

NFR3: System should handle up to 1000 concurrent users

NFR4: Response time for browsing and searching should be under 300ms

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Book catalog service

Shopping cart service

Order processing service

Payment processing interface and implementations

Notification service interface and implementations

Design Patterns

Interface segregation

Dependency injection

Strategy pattern for payment methods

Observer pattern for notifications

Single responsibility principle in service classes

Reference Architecture

  +-------------------+       +---------------------+       +---------------------+
  |   Book Catalog    |<----->|  Shopping Cart       |<----->|  Order Processing    |
  |   Service         |       |  Service            |       |  Service            |
  +-------------------+       +---------------------+       +---------------------+
           ^                             ^                             ^
           |                             |                             |
           |                             |                             |
  +-------------------+       +---------------------+       +---------------------+
  | Payment Interface  |<----->| Payment Implementations|     | Notification Interface|
  +-------------------+       +---------------------+       +---------------------+
                                                                ^           ^
                                                                |           |
                                                      +----------------+ +----------------+
                                                      | EmailNotifier  | | SMSNotifier    |
                                                      +----------------+ +----------------+

Components

Book Catalog Service

Plain classes with single responsibility

Manage book data and provide search and browse functionality

Shopping Cart Service

Class managing cart items and user sessions

Handle adding/removing books and cart state

Order Processing Service

Class coordinating order placement and payment

Process orders and trigger notifications

Payment Interface

Interface with multiple implementations (e.g., CreditCardPayment, PayPalPayment)

Define payment method contract to allow extension without modification

Notification Interface

Interface with implementations like EmailNotifier and SMSNotifier

Send order status updates using different channels

Request Flow

1. User requests book list from Book Catalog Service

2. Book Catalog Service returns filtered book data

3. User adds books to Shopping Cart Service

4. User places order via Order Processing Service

5. Order Processing Service calls Payment Interface implementation to process payment

6. On payment success, Order Processing Service triggers Notification Interface implementations

7. Notifications sent to user via email and/or SMS

Database Schema

Entities: Book(id, title, author, category, price), User(id, name, email), Cart(id, userId), CartItem(id, cartId, bookId, quantity), Order(id, userId, status, totalAmount), Payment(id, orderId, method, status), Notification(id, orderId, type, status) Relationships: User 1:N Cart, Cart 1:N CartItem, CartItem N:1 Book, User 1:N Order, Order 1:1 Payment, Order 1:N Notification

Scaling Discussion

Bottlenecks

Tight coupling between payment methods and order processing limits adding new payment types

Notification logic mixed with order processing makes adding new notification channels hard

Single large classes handling multiple responsibilities become hard to maintain

Synchronous payment processing can slow down order placement under load

Solutions

Use dependency inversion and interfaces to decouple payment methods from order processing

Apply observer pattern for notifications to allow multiple independent notification handlers

Refactor classes to follow single responsibility principle for easier maintenance

Use asynchronous processing and message queues for payment and notification to improve responsiveness

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing the system applying SOLID principles, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing

Explain how each SOLID principle applies to the design

Show how interfaces and abstractions enable easy extension

Discuss separation of concerns and single responsibility in services

Highlight how dependency inversion reduces coupling

Describe patterns used like strategy for payments and observer for notifications

Mention how design supports maintainability and scalability