Dependency Inversion Principle in LLD - System Design Exercise

Design: Dependency Inversion Principle Application

Focus on the design of the payment processing system applying the Dependency Inversion Principle. Out of scope are actual payment gateway integrations and UI design.

Functional Requirements

FR1: Design a simple payment processing system that supports multiple payment methods (e.g., credit card, PayPal, bank transfer).

FR2: The system should allow easy addition of new payment methods without changing existing code.

FR3: High-level modules (payment processing logic) should not depend on low-level modules (specific payment method implementations).

FR4: Both should depend on abstractions (interfaces).

FR5: Abstractions should not depend on details; details should depend on abstractions.

Non-Functional Requirements

NFR1: The system should be modular and maintainable.

NFR2: It should be easy to extend with new payment methods.

NFR3: Latency for processing a payment should be under 500ms.

NFR4: The system should be testable with mock payment methods.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

PaymentProcessor interface (abstraction)

Concrete payment method classes (e.g., CreditCardPayment, PayPalPayment)

High-level PaymentService that uses PaymentProcessor interface

Dependency injection mechanism to provide payment method implementations

Mock payment processors for testing

Design Patterns

Dependency Injection

Strategy Pattern

Interface Segregation

Inversion of Control

Reference Architecture

  +-------------------+       implements       +-----------------------+
  |  PaymentProcessor  |<-----------------------|  CreditCardPayment     |
  +-------------------+                        +-----------------------+
           ^                                         ^
           |                                         |
           |                                         |
  +-------------------+       uses              +-----------------------+
  |  PaymentService    |----------------------->|  PayPalPayment        |
  +-------------------+                        +-----------------------+
           |
           | uses
           v
  +-------------------+
  |  Client Code       |
  +-------------------+

Components

PaymentProcessor

Interface/Abstract Class

Defines abstraction for payment methods that high-level modules depend on.

CreditCardPayment, PayPalPayment, BankTransferPayment

Concrete Classes

Implement specific payment methods depending on PaymentProcessor abstraction.

PaymentService

Class

High-level module that processes payments using PaymentProcessor interface.

Dependency Injection Container

DI Framework or Manual Injection

Provides concrete payment method implementations to PaymentService without tight coupling.

MockPaymentProcessor

Mock Class

Used for testing PaymentService independently of real payment methods.

Request Flow

1. Client calls PaymentService to process a payment.

2. PaymentService depends on PaymentProcessor interface, not concrete classes.

3. Dependency Injection provides a concrete payment method implementation to PaymentService.

4. PaymentService calls processPayment() on the injected PaymentProcessor.

5. Concrete payment method executes payment logic.

6. Result is returned to PaymentService and then to Client.

Database Schema

Not applicable as this is a low-level design focusing on code structure and dependencies.

Scaling Discussion

Bottlenecks

Adding new payment methods may cause code duplication if not designed properly.

Tight coupling if abstractions are not well defined.

Testing difficulty if dependencies are hard-coded.

Performance overhead if dependency injection is misused.

Solutions

Use clear, minimal interfaces to reduce coupling and duplication.

Apply Dependency Injection to decouple modules and improve testability.

Use design patterns like Strategy to encapsulate payment algorithms.

Profile and optimize dependency injection usage to minimize overhead.

Interview Tips

Time: Spend 10 minutes explaining the principle and requirements, 20 minutes designing the system with diagrams and code structure, 10 minutes discussing scaling and testing.

Explain the Dependency Inversion Principle in simple terms.

Show how high-level modules depend on abstractions, not details.

Demonstrate how new payment methods can be added without changing existing code.

Discuss dependency injection and its role in decoupling.

Highlight testability improvements using mocks.

Mention potential bottlenecks and how to address them.