Thought - The Anatomy of a True Microservice
A true microservice architecture is not defined by the size of the container or the framework you use. It is defined by discipline.
Over the last two decades in the tech industry I have watched architectural trends wash over us like waves. I saw the rise and fall of SOA. I saw the reign of the Monolith. And now I see everyone rushing toward Microservices.
But after architecting over 100+ products I have noticed a troubling pattern.
Most teams are not building microservices. They are building what I call a Distributed Monolith. They take all the pain of a distributed system and combine it with the tight coupling of a monolith. It is the worst of both worlds. This is explained better in my last post on Deep Dive series.
A true microservice architecture is not defined by the size of the container or the framework you use. It is defined by discipline. It is defined by adherence to specific architectural laws that guarantee agility.
These are the five laws I have learned the hard way. If you violate them you are not building microservices you are building technical debt.
Law 1 - Zero Shared State
The most fundamental law of microservices is Shared Nothing.
In the old world data was the center of the universe. In a microservice world the Service is the center.
The Database Rule
A service must own its data exclusively. I often see teams pointing two services at the same tables to save time.
This is a trap. If the Billing Service wants to know a user’s address it cannot query the users table directly. It must ask the User Service via an API.
The Foreign Key Problem
This creates a challenge we must accept. How do you handle relationships without foreign keys?
Logical References
Instead of a database constraint I store the user_id as a simple UUID in the Billing database. It is a “soft link.”
Eventual Consistency
If the user is deleted the User Service emits an event. The Billing Service listens and decides what to do. We trade strict integrity for massive scalability.
Law 2 - Independent Deployability
This is my litmus test for engineering culture.
Can you deploy a breaking change to the Inventory Service on a Friday afternoon without talking to the team that runs the Checkout Service?
If the answer is no you have failed Law 2.
Consumer Driven Contracts (CDC)
To achieve this I rely on Consumer Driven Contracts. The consumer (Checkout) writes a test suite defining exactly what it expects from the provider (Inventory).
This runs automatically during the build process. It allows teams to move fast with the confidence that they are not breaking their neighbors.
Law 3 - Fault Isolation
I design systems with the assumption that everything will break. A true microservice architecture acts like the watertight compartments of a ship.
The Bulkhead Pattern
If the Image Processing Service is leaking memory and crashing it should be physically impossible for that failure to impact the User Login Service.
This means segregating thread pools and database connections. In a naive implementation services share resources. In a professional implementation they are isolated processes with hard limits
Law 4 - Smart Endpoints and Dumb Pipes
In the early 2000s we built massive Enterprise Service Buses (ESB) that contained complex routing logic.
That was a mistake.
Keep the Logic Local
I believe in Smart Endpoints. All business logic validation and transformation lives inside the microservice code.
The network (HTTP or Kafka) should be a Dumb Pipe. It does only one thing. It moves a message from A to B. It does not think. This ensures that the logic is versioned and deployed with the service not hidden in infrastructure configuration.
Law 5 - Decentralized Governance
The final freedom microservices give us is the freedom of technology.
In a monolith we were forced to use one language and one database for everything.
In my experience the best systems use the right tool for the job.
Polyglot Persistence
If I need fuzzy search I use Elasticsearch for that specific service.
If I need relationship mapping I use Neo4j.
If I need ACID compliance I use PostgreSQL.
Because these services communicate via standard APIs the internal implementation details do not matter to the outside world.
Conclusion
Building true microservices is hard. It requires you to give up the comfort of ACID transactions and simple SQL joins.
But in my twenty years of building systems I have found that this discipline is the only path to a system that can evolve adapt and survive at scale.