The Microservices Mistake That Made Me a Better Architect

A few years back, I designed a microservices architecture for a startup client of mine. All due diligence was done on technology selection, we spent weeks on the design and technically it was very good.

8 core services were identified, all event-driven and running within k8s. We had a sound tech stack.

Where Things Went Wrong

At first things seemed to be running smoothly, however after a few weeks deploying and running in Production the problems began to surface.

Engineers were having trouble debugging service-to-service communication and troubleshooting the distributed system flow end-to-end. Deployment dependencies were also getting increasingly complex to manage.

The team was spending more time on this overhead than delivering new features. The engineering effort outweighed the benefits.

Lessons Learnt

18 months in and a few lessons were learnt:

• Not everything has to be microservices. Some parts of systems function, deploy and troubleshoot easier as a monolith.
• Great architecture, and this may sound obvious, isn't necessarily adhering to industry trends or using the most sophisticated of tooling. It's far better to pick technology and tooling that the team size and maturity level can manage.
• Match technical decisions to product maturity level and actual business requirements. This also includes having decision registers, user journeys and architecture diagrams for teams to refer back to in future.

A Better Approach

Now when a client of mine asks for microservices, I am sure to ask them to articulate the why and what of the problem statement to make a case for or against a monolith or hybrid approach.

What's a technical decision you'd do differently now?