Microservices have gone from architectural buzzword to mainstream standard. But with adoption comes confusion. What exactly is a microservice? How do you design one well? And do traditional design principles still apply?

This article cuts through the hype. It offers a grounded view of what microservices are (and are not), how to design them sensibly, and where common principles help, or hurt.

Don’t Let Principles Design Your System

We’re taught to honor ideas like extensibility, reuse, cohesion, coupling, and the SOLID principles. But in practice, blindly applying them often backfires.

Extensibility Isn’t Always Worth It

Extensibility is the idea that future changes should require minimal code edits. Sounds great, until you guess wrong. You might build elaborate hierarchies and abstractions... only to discover the actual change is something else entirely.

Code is like people on a crowded bus—the more you have, the harder it is to get new things on board.

Extensibility done without insight leads to unnecessary complexity, not flexibility.

Reuse vs. Specificity

Reusable code must be general. Useful code must be specific. Trying to be both leads to bloated abstractions that serve neither. Reusability requires not just technical skill but deep understanding of the problem domain.

When Principles Backfire

Design principles aren’t wrong. But misusing them is easy.

Single Responsibility Principle (SRP) and Open/Closed Principle (OCP), for instance, often get applied dogmatically. Teams over-engineer in the name of purity—only to ship code that’s harder to read, change, or test.

Ask not: “Am I following the principle?”
Ask: “Is this helping the outcome?”

The Balancing Act: YAGNI vs. Extensibility

YAGNI: You Aren’t Gonna Need It: urges us to avoid speculative features. It’s a good guardrail against over-design. But too much YAGNI means under-preparing for known changes.

Find the Balance

• Too much extensibility ? unnecessary complexity
• Too much YAGNI ? repeated rework
• Goal: Plan for change without building for the imaginary

DRY Is About More Than Code

Don’t Repeat Yourself (DRY) is not just about eliminating duplicate lines. It’s about avoiding duplicated effort.

Examples of DRY violations:

• Manual testing
• Manual deployments
• Repeated hand-offs or coordination rituals

Automate the repeatable. Focus human energy on work that requires judgment.

What a Microservice Actually Is

It’s not just “a service with a REST endpoint.” It’s not about size.

A Better Definition

A microservice is a domain-aligned, independently deployable, and autonomously developed component that communicates over a well-defined interface.

Think of “micro” the way you think of a microscope: it doesn’t mean small in size, but narrow in focus.

Monoliths Aren’t the Enemy

Monoliths:

• Are faster to build and easier to debug
• Require less infrastructure
• Are cheaper for small teams
• Work well: until you scale team size and change frequency

For early-stage products, monoliths often outperform microservices in speed and simplicity.

If you’re a startup, build a monolith. Your goal is survival, not elegance.

The drawback? Any change requires touching the whole system. When many teams share the same codebase, agility suffers.

The Real Value of Microservices

1. Autonomy of Development

Teams can build and ship services independently.

2. Isolation of Deployment

Each service can be deployed without affecting others—if designed with proper semantic versioning.

3. Separation of Governance

Ownership is clear. Teams don’t need to coordinate every change with others.

But these gains come with costs:

• More infrastructure
• More tooling
• More coordination around contracts and versioning

Design is always about trade-offs.

Design Around Domains, Not Technology

A key mistake in system design is technology-based partitioning.

Bad partitioning:

• Frontend service
• Backend service
• Auth service

Good partitioning:

• Tax calculation service
• Claims processing service
• Inventory management service

This is called domain-based cohesion. It aligns systems with how the business thinks—not how engineers like to separate concerns.

Reuse vs. Coupling: You Can’t Have Both

Developers say:

“We want maximum reuse and minimal coupling.”

But those goals are in tension.

Optimize for	You get	But you also get
Reuse	Less duplication	More coupling
Low coupling	More autonomy	More duplication

There’s no free lunch. Be intentional about the trade-off you’re making.

Encapsulation Enables Agility

If services share a database, they’re not truly independent.

You wouldn’t make all your class variables public—so why expose your database schema to everyone?

Encapsulation lets teams evolve their services safely. Without it, any change risks cascading failures across the system.

On Consistency: Choose Your Pain

Everyone wants consistency. Few understand what it costs.

Strong consistency requires coordination. Coordination kills agility.

Sometimes it’s worth it. Often it’s not.

Never ask your business stakeholders: “Do you want consistency?”
Instead ask: “What’s the real cost of a brief inconsistency, and can we tolerate it?”

Design For Outcomes, Not Ideals

Many teams start with a checklist of principles. Better teams start with goals and work backwards.

Ask:

• What do we need—agility, autonomy, fault isolation?
• What’s the fastest, safest way to get there?
• What trade-offs are acceptable?

Principles are not rules. They are tools. Use them with judgment.

Final Thought: Trade-Offs Are the Design

Software design is not about choosing the best principle—it’s about choosing which downsides you’re willing to live with.

• You can’t maximize reuse and minimize coupling at the same time.
• You can’t have perfect encapsulation and zero duplication.
• You can’t follow all principles to the letter and still deliver on time.

Good design is about recognizing tension, making compromises, and staying focused on the outcomes that matter.

About This Article

This article distills ideas from Dr. Venkat Subramaniam’s talk, “Designing Microservices,” delivered at GIDS 2026. It captures the essence of his message: that thoughtful trade-offs and contextual application of principles matter far more than architectural trends or purity.