Mahmoud Abas, Full-Stack Software Engineer & AI

System Design & Design Patterns - Real-World Case Study: E-Commerce Order Processing System

In the print dialog, choose "Save as PDF" as the destination.

Real-World Case Study: E-Commerce Order Processing

Combining multiple design patterns in one system

The Problem

Handle different product types: physical, digital, subscription
Support multiple payment methods
Send notifications to various channels
Process orders with complex business rules
Support order modifications and cancellations

Pattern Integration Flow

Client

placeOrder(orderData)

OrderManagementFacade

Facade

createOrder()

OrderBuilder

Builder

createProduct(type, data)

ProductFactory

Factory

processPayment(order)

PaymentStrategy

Strategy

notifyStatusChange("paid")

NotificationSystem

Observer

execute(PlaceOrderCommand)

CommandInvoker

Command

order placed

OrderConfirmation

Creational Need

Factory for Products

python

class ProductFactory:
    @staticmethod
    def create_product(product_type, **kwargs):
        if product_type == "physical":
            return PhysicalProduct(**kwargs)
        elif product_type == "digital":
            return DigitalProduct(**kwargs)
        elif product_type == "subscription":
            return SubscriptionProduct(**kwargs)

Chooses the right product class at runtime by product_type

Creational Need

Builder for Orders

python

class OrderBuilder:
    def __init__(self):
        self.order = Order()

    def add_product(self, product):
        self.order.products.append(product)
        return self

    def set_customer(self, customer):
        self.order.customer = customer
        return self

    def build(self):
        return self.order

Assembles an order step by step, fluently, chaining calls that each return self

Structural Need

Decorator for Processing

python

class OrderProcessorDecorator:
    def __init__(self, processor):
        self.processor = processor

    def process(self, order):
        return self.processor.process(order)

class TaxCalculatorDecorator(OrderProcessorDecorator):
    def process(self, order):
        result = self.processor.process(order)
        # add tax calculation
        return result

Layers tax and shipping calculation onto order processing without touching the base process method

Structural Need

Facade for Coordination

python

class OrderManagementFacade:
    def __init__(self):
        self.inventory = InventoryService()
        self.payment = PaymentService()
        self.shipping = ShippingService()

    def place_order(self, order):
        self.inventory.reserve_items(order.products)
        result = self.payment.process_payment(order)
        if result.success:
            self.shipping.schedule_delivery(order)
        return result

One entry point orchestrates inventory, payment, and shipping

Behavioral Need

Strategy for Payment

python

class PaymentProcessor:
    def __init__(self):
        self.strategy = None

    def set_payment_strategy(self, strategy):
        self.strategy = strategy

    def process_payment(self, order):
        return self.strategy.pay(order.total_amount)

Swaps credit card, PayPal, or crypto without changing the processor

Behavioral Need

Observer for Status Updates

python

class Order(Subject):
    def __init__(self):
        super().__init__()
        self._status = "pending"

    @status.setter
    def status(self, new_status):
        self._status = new_status
        self.notify(f"Order status changed to {new_status}")

Email and SMS notifications subscribe without coupling to the Order

Behavioral Need

Command for Operations

python

class PlaceOrderCommand(Command):
    def __init__(self, order_service, order):
        self.order_service = order_service
        self.order = order

    def execute(self):
        return self.order_service.place_order(self.order)

    def undo(self):
        return self.order_service.cancel_order(self.order)

Placing and cancelling an order become interchangeable, undoable actions via execute and undo

Pattern Selection Decision Tree

Object Creation

simple

Direct Constructor

multiple types

Factory Pattern

many parameters

Builder Pattern

single instance

Singleton Pattern

Interface Compatibility

incompatible

Adapter Pattern

add behavior

Decorator Pattern

simplify complex

Facade Pattern

Communication

one-to-many updates

Observer Pattern

multiple algorithms

Strategy Pattern

queue/undo operations

Command Pattern

Putting It All Together

Builder creates the order
Factory creates each product inside it
Strategy processes the payment
Observer notifies the customer of status changes
Decorator layers on tax and shipping calculations
Command executes the order with undo support
Facade coordinates every service behind one call

Pattern Selection Reasoning

Pattern	Problem Solved	Why Chosen	Alternative Considered
Factory	Different product types	Runtime type determination	Direct instantiation (too rigid)
Builder	Complex order creation	Many optional parameters	Constructor overloading (unwieldy)
Strategy	Payment methods	Runtime algorithm switching	If-else chains (hard to extend)
Observer	Notifications	Decoupled communication	Direct method calls (tight coupling)
Decorator	Order processing	Flexible responsibility chain	Inheritance (explosion of classes)
Command	Order operations	Undo/redo + queuing	Direct method calls (no undo)
Facade	System complexity	Simplified interface	Direct service calls (complex client)

Key Takeaways

Real systems combine multiple patterns, not just one
Creational patterns (Factory, Builder) tame object creation complexity
Structural patterns (Decorator, Facade) manage composition and simplify APIs
Behavioral patterns (Strategy, Observer, Command) manage communication and operations
Start from the problem, then pick the pattern, never force a pattern in

Open this lesson

Mahmoud AbasReal-World Case Study: E-Commerce Order Processing System

class ProductFactory: @staticmethod def create_product(product_type, **kwargs): if product_type == "physical": return PhysicalProduct(**kwargs) elif product_type == "digital": return DigitalProduct(**kwargs) elif product_type == "subscription": return SubscriptionProduct(**kwargs)

class OrderBuilder: def __init__(self): self.order = Order() def add_product(self, product): self.order.products.append(product) return self def set_customer(self, customer): self.order.customer = customer return self def build(self): return self.order

class OrderProcessorDecorator: def __init__(self, processor): self.processor = processor def process(self, order): return self.processor.process(order) class TaxCalculatorDecorator(OrderProcessorDecorator): def process(self, order): result = self.processor.process(order) # add tax calculation return result

class OrderManagementFacade: def __init__(self): self.inventory = InventoryService() self.payment = PaymentService() self.shipping = ShippingService() def place_order(self, order): self.inventory.reserve_items(order.products) result = self.payment.process_payment(order) if result.success: self.shipping.schedule_delivery(order) return result

class PaymentProcessor: def __init__(self): self.strategy = None def set_payment_strategy(self, strategy): self.strategy = strategy def process_payment(self, order): return self.strategy.pay(order.total_amount)

class Order(Subject): def __init__(self): super().__init__() self._status = "pending" @status.setter def status(self, new_status): self._status = new_status self.notify(f"Order status changed to {new_status}")

class PlaceOrderCommand(Command): def __init__(self, order_service, order): self.order_service = order_service self.order = order def execute(self): return self.order_service.place_order(self.order) def undo(self): return self.order_service.cancel_order(self.order)

Pattern

Problem Solved

Why Chosen

Alternative Considered

Factory

Different product types

Runtime type determination

Direct instantiation (too rigid)

Builder

Complex order creation

Many optional parameters

Constructor overloading (unwieldy)

Strategy

Payment methods

Runtime algorithm switching

If-else chains (hard to extend)

Observer

Notifications

Decoupled communication

Direct method calls (tight coupling)

Decorator

Order processing

Flexible responsibility chain

Inheritance (explosion of classes)

Command

Order operations

Undo/redo + queuing

Direct method calls (no undo)

Facade

System complexity

Simplified interface

Direct service calls (complex client)