Most of us learn SOLID as a code skill: better classes, cleaner interfaces, fewer side effects. Then we move into architecture with services, platforms, teams, cloud, and SOLID quietly fades into the background.
That’s a miss.
SOLID doesn’t stop being true at scale. What changes is the unit of design.
In code, your unit is a class.
In architecture, your unit becomes a service, module, subsystem, API, event stream, or team-owned capability.
If you want practical value from SOLID in real production systems, ask a different question:
“How do I apply SOLID to boundaries?”
Below is a no-nonsense translation of SOLID from classes to systems, plus concrete checks you can apply immediately.
1) Single Responsibility Principle (SRP): Responsibility = a Capability, not a “Bucket”
At system scale, SRP means: one service/module owns one primary business capability end-to-end, including its core logic, data rules, and lifecycle.
The common failure mode is creating “bucket services” with vague ownership, for example:
“CustomerService owns customer-related stuff.”
That sounds reasonable, but “customer-related” has no natural boundary. Over time it tends to absorb unrelated capabilities that change for different reasons, such as profile CRUD, consent, segmentation attributes, credit checks, support cases, and notifications. The result is low cohesion, lots of dependencies, and constant coordination across teams.
What “one capability” looks like (examples)
Instead of one big “CustomerService”, SRP aligned services are typically scoped by clear capabilities, for example:
Customer Profile Service: manage customer master data and profile lifecycle (create/update/merge/deactivate).
Customer Consent Service: capture and audit consent, enforce privacy/regulatory rules.
Customer Credit Service: calculate eligibility and make credit decisions.
These are all “customer-related”, but they are not the same responsibility. They evolve differently and should not be forced into the same deployable unit and release cycle.
Practical checks (use in design reviews)
Can you describe the service in one clear verb phrase?
Examples: “Manage customer profile”, “Authorize payments”, “Generate invoices”, “Calculate pricing”.
If your description needs multiple “and” clauses (“…and billing and shipping…”), it’s likely doing too much.·Do changes come mostly from one type of business change?
If the service changes for privacy regulation updates and credit policy tweaks and support workflow changes, it’s probably a bucket.Does the team own the full capability, not just code?
Ownership should include the key data, rules, and operational responsibility for that capability.
Smell
A service becomes a “shared utilities + random endpoints” dumping ground because “everyone needs it.”
Immediate action
Rename and reshape services/modules around capability-oriented names that force clarity, for example:
Noun + role: InvoiceGenerator, PriceCalculator, PaymentAuthorizer
Capability service naming: InvoicingService, PricingService, PaymentsService
The point isn’t the grammar. The point is that the name should make the capability boundary obvious and make it harder to justify “just one more endpoint because it’s related.”
2) Open/Closed Principle (OCP): Extend via Contracts, not via Coupling
In code, OCP says: add behavior without modifying existing code.
At scale, OCP means: evolve the system by adding new providers or new consumers behind stable contracts, without forcing coordinated changes across many teams.
Example: You add a new “Buy Now, Pay Later” payment provider by plugging it behind the existing PaymentAuthorization contract, so checkout does not need a rewrite.
The “extension mechanism” is usually:
• API contracts (REST/gRPC)
Example: Keep POST /payments/authorize stable and add paymentMethod=BNPL as a new supported option, instead of creating a new checkout flow.
• Event contracts (schemas)
Example: Publish an OrderPlaced event. A new Fraud service subscribes and reacts, without changing the Order service at all.
• Plugin-like provider models
Example: An ITaxCalculator style provider interface at system level: different tax engines can be swapped per country or tenant without changing the ordering workflow.
Practical checks
• Can a new consumer start using your service without you changing internal code?
Example: A new Analytics service subscribes to InvoiceGenerated events. The Invoicing service does not change, it already emits the event contract.
• Can you introduce a new provider implementation (or version) without every consumer needing changes at the same time?
Example: Move from CustomerScoringV1 to CustomerScoringV2 behind the same API contract and error semantics, then switch traffic gradually from V1 to V2, while consumers keep calling the same API contract and they are never aware of V1 and V2
Smell
• “We need to update 7 services and redeploy everything together.” That’s the system-scale equivalent of a giant switch statement.
Example: Checkout, Payments, Orders, Notifications, and Shipping must all be updated just to add a new payment method because the new behavior is wired through direct, brittle dependencies instead of a contract.
Immediate action
• Make contract changes additive by default: add new fields, endpoints, or events; avoid breaking existing ones.
Example: Add discountBreakdown to the pricing response, but keep totalPrice unchanged so existing consumers still work.
• Publish versioning rules (even a one-page “contract evolution policy” is a big step).
Example rules: no breaking changes without a new version, additive fields must be optional, support old and new versions for a defined deprecation window.
3) Liskov Substitution Principle (LSP): Can You Swap Providers Without Breaking Consumers?
In code: subclasses must be substitutable for base classes.
At scale: if multiple implementations exist behind one contract (versions, vendors, regional providers, new vs legacy), consumers must not care which one they get.
This matters more than people think because “replacement” happens constantly:
v1 -> v2 of a service
legacy system replaced by a new platform
different provider per geography/tenant
fallback provider during incidents
Practical checks
If you route traffic from Provider A to Provider B, do consumers still work without changes?
Are error semantics consistent (status codes, retry behavior, idempotency, timeouts)?
Smell
“Same endpoint, different behavior” across environments/tenants.
v2 exists, but everyone stays on v1 because upgrading breaks assumptions.
Immediate action
Define behavioral contracts, not just payloads:
idempotency rules
ordering guarantees
error model
timeout expectations
retry safety
4) Interface Segregation Principle (ISP): Don’t Force Teams to Depend on What They Don’t Use
In code: small interfaces beat fat ones.
At scale: avoid “one big service interface” that becomes a dependency magnet. Prefer small, purpose-specific APIs or event streams.
A large interface creates hidden coupling:
consumers depend on shared release cycles
permissions/security become messy (“who can call what?”)
it becomes harder to change anything safely
Practical checks
Does your service have endpoints that exist “because someone might need it someday”?
Are there consumers that only need 10% of the API but must onboard the whole thing (auth scopes, SDKs, docs, governance)?
Smell
· A single “Platform API” becomes the central highway for everything. Congestion follows.
Immediate action
Slice interfaces by consumer purpose:
“Read model API” vs “Command API”
separate event topics by domain event type
separate admin/ops APIs from business APIs
5) Dependency Inversion Principle (DIP): Workflows Depend on Abstractions, Not Concrete Services
In code: depend on interfaces, not implementations.
At scale: high-level workflows should depend on stable abstractions, contracts, topics, gateways and not hardwired service-to-service calls.
This is where many architectures accidentally become brittle: Service A directly calls Service B directly calls Service C… and every change ripples.
Practical checks
Can you replace a downstream provider via configuration/routing without code changes?
Can you test high-level workflows with mocks/stubs because contracts are clear?
Smell
Service discovery endpoints or URLs are embedded all over the codebase.
“We can’t change B because A assumes B’s internal details.”
Immediate action
Introduce an abstraction layer where it matters most:
API gateway / facade for stable entry points
event-driven integration for loose coupling
contract-first APIs with generated clients
configuration-based routing (feature flags, provider selection)
The System-Scale SOLID Cheat Sheet: Use this in Design Reviews
When reviewing a service/module/system boundary, ask:
SRP: What capability does it own end-to-end? What capability does it not own?
OCP: How do we extend behavior without forcing coordinated change?
LSP: If we swap providers/versions, do consumers still work?
ISP: Are consumers forced to depend on endpoints/events they don’t use?
DIP: Are workflows coupled to concrete services, or to stable contracts?
If you can answer these in plain language, you’re doing SOLID at system scale.
Closing Thought
The textbook teaches SOLID as a coding guideline. Production teaches you that the same ideas become coordination tools: they reduce cross-team friction, release coupling, and integration breakage.
When you design systems, are you thinking in classes… or in capabilities and contracts?
What’s your biggest challenge applying SOLID at scale: Service boundaries, contract versioning, or release coordination?