Liskov Substitution Principle in LLD - Scalability & System Analysis

Scalability Analysis - Liskov Substitution Principle

Growth Table: Liskov Substitution Principle (LSP) in System Design

Users / Scale	Design Impact	Code Maintainability	System Flexibility	Bug Risk
100 users	Simple inheritance works fine	Easy to manage small codebase	Low need for strict LSP enforcement	Low risk of substitution bugs
10,000 users	More subclasses added for features	Moderate complexity; LSP helps avoid surprises	Important for swapping components safely	Medium risk if LSP ignored
1,000,000 users	Many modules and services depend on abstractions	High complexity; LSP critical for safe extensions	High need for polymorphism and substitutability	High risk of system failures if LSP violated
100,000,000 users	Distributed systems with many interchangeable parts	Very high complexity; LSP essential for microservices	Must guarantee substitutability across services	Severe impact on reliability if LSP broken

First Bottleneck: Violations of Liskov Substitution Principle

At small scale, ignoring LSP causes minor bugs. But as system grows, violating LSP leads to unexpected behavior when replacing components or subclasses.

This breaks polymorphism, causing runtime errors, inconsistent data, and system crashes.

The first bottleneck is maintainability and reliability of the codebase, which directly affects system stability and scalability.

Scaling Solutions for Liskov Substitution Principle

• Strict Interface Contracts: Define clear, minimal interfaces that subclasses must follow.
• Automated Testing: Use unit and integration tests to verify subclass behavior matches expectations.
• Code Reviews: Enforce LSP adherence during peer reviews to catch violations early.
• Refactoring: Regularly refactor code to simplify inheritance hierarchies and remove violations.
• Use Composition over Inheritance: Favor composition to reduce tight coupling and substitution issues.
• Documentation: Clearly document expected behavior and side effects for subclasses.

Back-of-Envelope Cost Analysis

Assuming a system with 1 million users and 100 microservices:

• Each service has ~10 subclasses implementing interfaces.
• Testing each subclass thoroughly requires ~1000 test cases per service.
• Automated tests run ~10 minutes per service, totaling ~1000 minutes (~17 hours) per full test cycle.
• Code review time increases linearly with number of subclasses; enforcing LSP reduces bug-fixing time later.
• Cost of ignoring LSP: increased downtime, bug fixes, and customer impact, which can be orders of magnitude higher.

Interview Tip: Structuring a Scalability Discussion on LSP

Start by explaining what LSP means in simple terms: subclasses should behave like their parent classes without surprises.

Discuss how violating LSP causes bugs that grow with system size.

Explain how enforcing LSP improves maintainability and scalability.

Give examples of solutions like testing, code reviews, and design choices.

Conclude with how this principle supports building reliable, scalable systems.

Self Check Question

Your system's database handles 1000 queries per second (QPS). Traffic grows 10x, and you add more subclasses to support new features. You notice bugs when replacing subclasses. What do you do first?

Answer: Review and enforce the Liskov Substitution Principle by ensuring all subclasses fully comply with the base class contracts. Add tests to verify substitutability and refactor violating subclasses to prevent runtime errors and maintain system stability.

Key Result

Liskov Substitution Principle is crucial for maintaining system reliability and scalability as the number of users and components grows; violating it leads to increasing bugs and system failures, which can be mitigated by strict interface contracts, testing, and refactoring.

Practice

1.

What does the Liskov Substitution Principle (LSP) primarily ensure in system design?

easy

A. Child classes can replace parent classes without affecting correctness

B. Parent classes must never be extended

C. Child classes should have fewer methods than parent classes

D. Parent classes should depend on child classes

Solution

1. Step 1: Understand LSP definition

   LSP states that objects of a child class should be replaceable with objects of the parent class without breaking the program.

2. Step 2: Analyze options against LSP

   Only Child classes can replace parent classes without affecting correctness correctly describes this principle. Other options contradict LSP or are unrelated.

3. Final Answer:

   Child classes can replace parent classes without affecting correctness -> Option A

4. Quick Check:

   Liskov Substitution Principle = Child replaces Parent [OK]

Hint: LSP means child works anywhere parent is expected [OK]

Common Mistakes:

• Thinking LSP forbids inheritance
• Confusing LSP with interface segregation
• Believing child classes can change parent behavior arbitrarily

2.

Which of the following class declarations follows the Liskov Substitution Principle?

class Bird {
  fly() {}
}

class Penguin extends Bird {
  fly() {
    throw new Error('Cannot fly');
  }
}

easy

A. Yes, because Penguin is a Bird

B. No, because Penguin breaks expected behavior of Bird

C. Yes, because Penguin overrides fly method

D. No, because Bird should not have fly method

Solution

1. Step 1: Analyze Penguin's fly method

   Penguin throws an error on fly(), but Bird expects fly() to work normally.

2. Step 2: Check LSP compliance

   Since Penguin cannot be used where Bird is expected (fly method fails), it violates LSP.

3. Final Answer:

   No, because Penguin breaks expected behavior of Bird -> Option B

4. Quick Check:

   Child must not break parent behavior = No [OK]

Hint: Child must not break parent's expected methods [OK]

Common Mistakes:

• Ignoring method behavior changes in child
• Assuming inheritance alone guarantees LSP
• Thinking overriding with error is allowed

3.

Consider the following code snippet. What will be the output?

class Vehicle {
  start() { return 'Vehicle started'; }
}

class Car extends Vehicle {
  start() { return 'Car started'; }
}

function startVehicle(v) {
  return v.start();
}

const myCar = new Car();
console.log(startVehicle(myCar));

medium

A. 'Vehicle started'

B. Error: start is not a function

C. 'Car started'

D. undefined

Solution

1. Step 1: Understand method overriding

   Car overrides start() method to return 'Car started'.

2. Step 2: Trace function call

   startVehicle(myCar) calls myCar.start(), which returns 'Car started'.

3. Final Answer:

   'Car started' -> Option C

4. Quick Check:

   Overridden method returns child's message [OK]

Hint: Child method overrides parent, so child's output shows [OK]

Common Mistakes:

• Expecting parent method output instead of child's
• Confusing method names or forgetting override
• Assuming error due to polymorphism

4.

Identify the violation of Liskov Substitution Principle in the code below and select the fix.

class Rectangle {
  setWidth(w) { this.width = w; }
  setHeight(h) { this.height = h; }
  area() { return this.width * this.height; }
}

class Square extends Rectangle {
  setWidth(w) {
    this.width = w;
    this.height = w;
  }
  setHeight(h) {
    this.width = h;
    this.height = h;
  }
}

medium

A. Use separate classes without inheritance for Square and Rectangle

B. Square should not override setWidth and setHeight

C. Square should only override area() method

D. No violation, code is correct

Solution

1. Step 1: Identify LSP violation

   Square changes behavior of setWidth and setHeight, breaking Rectangle's expectations.

2. Step 2: Choose fix

   To follow LSP, Square and Rectangle should not be in inheritance relation if behaviors differ fundamentally.

3. Final Answer:

   Use separate classes without inheritance for Square and Rectangle -> Option A

4. Quick Check:

   Different behavior means no inheritance [OK]

Hint: If child changes parent's method meaning, avoid inheritance [OK]

Common Mistakes:

• Ignoring behavioral changes in overridden methods
• Trying to fix by only overriding area()
• Assuming inheritance always fits shapes

5.

You are designing a payment system with a base class PaymentMethod and subclasses CreditCard and Bitcoin. The base class has a method processPayment(amount) that returns a success message. However, Bitcoin payments require additional confirmation steps and may fail differently. How should you design these classes to follow the Liskov Substitution Principle?

hard

A. Make processPayment abstract and force subclasses to implement their own versions ignoring base behavior

B. Make Bitcoin inherit PaymentMethod and override processPayment to throw errors on failure

C. Remove inheritance and implement separate interfaces for each payment type

D. Keep Bitcoin and CreditCard as subclasses but ensure processPayment behaves consistently and returns success/failure uniformly

Solution

1. Step 1: Understand LSP in payment context

   Subclasses must behave so they can replace base class without breaking client code.

2. Step 2: Design consistent behavior

   Bitcoin and CreditCard should implement processPayment so it returns success/failure in a consistent way, hiding internal differences.

3. Final Answer:

   Keep Bitcoin and CreditCard as subclasses but ensure processPayment behaves consistently and returns success/failure uniformly -> Option D

4. Quick Check:

   Consistent behavior across subclasses = LSP compliance [OK]

Hint: Subclasses must behave consistently to replace parent safely [OK]

Common Mistakes:

• Throwing errors breaking expected method contracts
• Ignoring different failure modes without abstraction
• Removing inheritance unnecessarily