SOLID Principles (for System Design)
Design boundaries so services stay maintainable — single responsibility per service, stable interfaces, dependency inversion via APIs.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where SOLID Principles (for System Design) is non-negotiable.
① What it is (30 seconds)
Design boundaries so services stay maintainable — single responsibility per service, stable interfaces, dependency inversion via APIs.
② How it works in system design
In SD interviews: decompose by domain capability (SRP). Extend via new services not fat classes (OCP). Interface contracts between teams (DIP). Bounded contexts prevent tight coupling.
Typical placement
Client→Edge / Gateway→SOLID→Services→Data stores
③ Concrete system design example
Scenario: Uber: separate Location, Matching, Trip, Payment services. Payment team exposes charge API — Trip service never touches card data directly (interface segregation).
④ Important interview Q&A
| Question | Answer |
|---|---|
| SOLID in microservices? | Each service one business capability; communicate via events/APIs not shared DB. |
| When monolith OK? | Early MVP — still apply module boundaries inside monolith for later split. |
| Anti-pattern? | Distributed monolith — many services deployed together sharing DB schema. |
⑤ Seen in these system designs
- Uber / Rides — service split
- Payment System — isolated PCI boundary
- Google Docs — editor vs storage
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Service boundaries
- Stable APIs
- No shared mutable DB across domains
- MVP vs microservices trade-off