Microservices building blocks
Most teams don’t struggle with microservices themselves — they struggle with everything around them.
I’m not going to argue whether microservices are good or bad. Instead, let’s talk about the building blocks they rely on.
Microservices don’t live in isolation. Every service:
- talks to a database
- publishes or consumes messages (queues, topics)
- depends on infrastructure: health checks, lifecycle management, metrics, tracing
And these integrations are rarely unique. Across services, you keep solving the same problems:
- DB and queue clients
- configuration and bootstrap
- health endpoints
- logging, metrics, tracing
That’s why teams inevitably end up with shared building blocks.
So what are the options?
In practice, it’s usually a mix of:
- copy-paste
- service templates (boilerplate)
- shared/platform libraries
Copy-paste works — until it doesn’t. Rolling out changes across dozens of services quickly turns into a mess.
That’s why I usually lean toward a platform library.
Get Mike’s stories in your inbox
Join Medium for free to get updates from this writer.
A typical structure might look like (here golang):
builder/ common/ consts/ health/ logging/ redis/ tracing/
bus/ configs/ grpc/ kafka/ metrics/ security/This approach makes it easier to:
- reuse integrations
- test things once
- evolve infrastructure consistently
It also pairs well with service templates, so developers can focus on business logic instead of wiring.
But there’s a trade-off.
Without strict versioning and compatibility rules, a platform library easily turns into a “god library” — tightly coupled, hard to upgrade, and slowing everyone down.
Rule of thumb:
If you have more than a handful of services, start with shared building blocks — but treat them like a product, not a dump of utilities.
P.S. Multi-language environments break this model in interesting ways — but that’s a separate headache.
