MicroNotes V: Information Hiding — The Discipline That Makes Microservices Work

Notes from Sam Newman’s Microservices Workshop — Bangkok 2025

So ***you’ve thought about why you might want microservices***. Maybe you’ve decided they make sense for your situation. You want that independent deployability. But here’s the thing: independent deployability doesn’t just happen. It requires loose coupling.

Easy to say. Hard to do. Making it happen requires discipline.

Sam Newman says there’s one concept so important, it’s why he wrote the second edition of his book:

“Information hiding”

At first glance, it sounds academic. Like something from a computer science paper. But it’s actually the key to making microservices work.

This is the concept that makes everything else work. Let’s see why.

The Independent Deployability Problem

Independent deployability sounds great. Deploy one service without deploying others. But there’s a catch.

You deploy a new version of the inventory service. Both returns and shipping depend on it.

The worry is real:

“The new version might break something.”

To actually do independent deployability, you need to be good at:

• Backwards compatibility
• Loose coupling
• Operating distributed systems

It’s not magic. It takes discipline. And that discipline starts with how you design services.

What Is Information Hiding?

Sam took us back to 1971. David Parnas wrote a paper called “On the Criteria to be Used in Decomposing Systems into Modules.” (Boring title, but Sam said it’s actually readable.)

Parnas was trying to figure out the best way to break a system into modules. He tried different things. Maybe each step of a program could be a module. One, then another, then another. Still too much coupling.

He worked through a bunch of approaches and came up with

“information hiding.”

The Core Idea

Hide things that are most likely to change behind a stable boundary.

If code is likely to change, hide it inside a module. When it changes, it can’t affect users of that module. The boundary protects them.

Parnas used “information” on purpose. Not “data.” Not “code.” Not “implementation.” Information, in the broadest sense.

He even said (when someone asked years later) that you shouldn’t necessarily have access to the source code of modules you use.

Hide everything. Expose only what’s needed.

What Makes a Good Module?

Before diving deeper, Parnas defined what makes good modular design. Three criteria:

1. Parallel work: Can different teams work on different modules in parallel?
2. Comprehensibility: Does the boundary make the system easier to understand?
3. Flexibility: Can you change one thing independently of another? This is the big one for microservices.

Parnas wasn’t thinking about independent deployability. He was thinking about monoliths where you still build and deploy everything together. But the ideas translate.

Most of us don’t think about modularity in our own code.

We do with third-party libraries. We use their API, we don’t care about internals. But we don’t apply that to our own code.

And programming languages don’t help much. Java had packages, but module support was poor for a long time. It’s getting better, but we still can’t really swap modules at runtime.

Information Hiding for Microservices

Sam takes Parnas’s idea and pushes it to an extreme for microservices.

• In a modular monolith: Get a boundary wrong? Annoying but manageable. Refactor, redeploy. Done.
• In microservices: Get a boundary wrong? Expensive. Move data. Change integrations. Coordinate deployments. Lots of work.

Everything is hidden unless it’s needed.

Don’t expose anything outside your microservice unless someone actually needs it. If someone needs it, expose it. But once you expose it, it’s part of your interface. You have to maintain it.

You have to maintain backwards compatibility. It’s a commitment.

The Maximal Exposure Problem

Sam showed us what happens when you don’t hide information. He called it “maximal exposure.”

The Scenario

Imagine an account service. You think: “I want to be helpful. I’ll give consumers access to everything they might want.” So you expose all your data structures, all your methods, everything.

The shipping service can access anything. Seems great at first. You’ve covered all bases. They can’t ask for anything else.

The Problem

But now you need to change something. Let’s say you need to change a database column. You want to make it not nullable. You look at the table, see it has no nullable fields currently, so making it not nullable should be fine.

But wait. The shipping service writes to this table. If you make that column not nullable, and shipping tries to insert null, you’ll break compatibility.

Finding out if this change is safe requires:

1. Look at shipping service code (if you have access)
2. Hope the team knows about this dependency
3. Hope the code is maintained
4. Maybe talk to the team

But here’s the problem: if you’ve exposed everything, almost every change becomes potentially dangerous.

Every change requires:

• Huge amounts of checking
• Double checking
• Triple checking
• Trying to find out what’s going on in all services using your service

It becomes expensive. It becomes scary.

The German Bank Story

This isn’t theoretical. Sam told us a real worst-case example. He was working at a German investment bank

They needed to change a database structure to improve performance. They found multiple applications across the bank accessing their data. Lucky for them, it was only reads. But they had a problem.

They didn’t know how many applications were accessing it, because they all had the same username and password.

So they had to:

1. Get networks team to trace inbound IPs
2. Map those back to servers
3. Look up servers in the configuration database
4. Find which cost centers those machines were in
5. Contact project managers
6. Ask which teams were running software on those machines

They tracked down some teams that way. Not all.

In the end, they turned the database account off and waited for angry phone calls.

The Information Hiding Solution

With information hiding, you’re explicit about what’s safe and what’s dangerous.

Safe Zone

Everything inside the service boundary (the “green box”) is hidden. You can do anything you want:

• Rename things
• Restructure things
• Change the database
• Refactor code

It can’t affect your consumers. They can’t see it.

Danger Zone

Everything on the boundary — anything exposed — is potentially dangerous. That’s what you must be careful about.

If you clearly separate these in your code, developers know:

“This stuff is safe. I can change it freely. This stuff is dangerous. I need to be careful.”

Practical Implications

Maybe you let less experienced developers work freely in the safe zone. But if they’re working on the interface, you:

• Pair program
• Add extra tests
• Verify changes carefully

Sam likes using explicit service schemas. They help catch breaking changes. But the principle is simple:

The more you hide, the more you can change safely.

Why This Matters

This concept became so important to Sam that it’s why he wrote the second edition. The idea rolled around in his head for six years.

“Information hiding, coupling, and cohesion are all linked.”

Information hiding reduces implementation coupling between services.

He also mentioned hexagonal architecture. Ports and adapters. It’s all connected.

For microservices, it’s clear:

If you want independent deployability, you need loose coupling. And information hiding is how you get loose coupling.

What to Remember

If you want independent deployability, you need information hiding.

Think of your service like a house: Inside, you can rearrange furniture, paint walls, change anything. But the front door? The windows? That’s your interface. Change them carelessly and the neighbors notice.

Information hiding means:

• Hide everything inside your service
• Expose only what someone actually needs
• Maintain whatever you expose
• Keep it backwards compatible

The problem with exposing everything is simple: Every change becomes risky. Every change becomes scary.

With information hiding, you get a clear separation:

• Inside: do whatever you want
• Outside: make changes carefully

This discipline is what keeps microservices from turning into a distributed monolith.

The question to ask is not “What can I expose?” but “What do I need to hide?”

Hide everything. Expose carefully. Because once it’s exposed, it’s a contract.

The best service boundary is the one you can change without asking permission.

Information hiding makes that possible.

***All Notes

---

***I: What Are Microservices? II: Forget Service Size — Focus on What Your Team Can Manage III: Microservices Aren’t About Technology — They’re About Team Autonomy IV: Nobody Cares About Your Microservices — Only the Outcome V: Information Hiding — The Discipline That Makes Microservices Work VI: Request-Response vs Event-Driven — Choosing How Services Talk VII: Distributed Transactions Are Sad — Use Sagas Instead VIII: Designing Microservices for the Edge — Lessons from Fish Farming IX: Testing Microservices — Beyond the Test Pyramid X: Migrating to Microservices — Changing the Wheels While the Car Is Moving XI: Domain-Driven Design — Speaking the Same Language XII: Breaking Apart Databases — When Data Becomes the Problem XIII: Resiliency, Observability, and the Reality of Distributed Systems

---