Architecture Revamp — And It Wasn’t What You’d Expect

Today, I want to share the story of my first major architectural revamp — one that I was deeply involved in from the ground up. If your first thought is, “Ah, must be about moving from monolith to microservices,” then… you're actually wrong.

The architectural shift I was part of went the other way around — from a distributed system back to a monolithic architecture.

In today's world, it feels like every other developer wants to hop on the microservices bandwagon. And sure, many have valid reasons. But let's be honest — a lot of us don’t fully understand why we’ve chosen the architecture we’re working with. It's so important to think critically about what we're building and what we expect from it.

Designing system architecture is a balancing act. Underthink it, and you risk ending up with a fragile system that doesn’t scale or adapt. Overthink it, and you might waste time or get stuck in analysis paralysis. The goal is to find that sweet spot between agility and foresight.

Context

A few years ago, I joined a startup — and more specifically, I became the first official employee. That meant I got the chance to work closely with the founding team, which was an incredible learning opportunity.

Let’s talk about the system.

The architecture was based on the CQRS pattern and had quite a bit of complexity. It combined multiple technologies including:

• Java with Spring Boot for core application logic
• MongoDB to store final data representations for the APIs
• Neo4j to handle graph-based relationships between entities
• Kafka for event-driven communication

On paper, it all sounded exciting. But reality had other plans.

Problems

The architecture wasn't terrible, but it wasn’t the right fit either — especially for where the company was at the time. Here’s why:

• It was still an early-stage startup. We should’ve prioritized simplicity.
• Making even small changes or bug fixes was far from easy.
• The codebase wasn't maintainable. Services were tightly coupled.
• Infrastructure dependencies (Kafka, Zookeeper, etc.) were heavy and fragile.

At some point, I started asking questions:
Why was this architecture chosen? Were simpler alternatives even considered?

That line of questioning eventually lit the spark that led to a complete rethinking of the system.

Suggestion

You might be surprised, but the suggestion I made was — let’s move to a monolithic architecture.

Just Java, Spring Boot, and PostgreSQL. That’s it. Simple, clean, minimal infrastructure. All we needed was the application server and a database.

The team was surprisingly receptive to the idea. But naturally, concerns came up — especially around the graph-based algorithms we were running on Neo4j. Would those even be possible in a relational DB? And would they be performant?

Experts on the team took that as a challenge. They rewrote the algorithms to work with PostgreSQL and tested them rigorously. The results were promising — performance was on par, and the complexity was manageable.

That marked the beginning of our journey: moving away from a distributed, multi-tech stack to a cleaner, more cohesive monolith.

Conclusion

Architecture decisions can define the future of a product — they really can make or break it.

In our case, we were fortunate. The CQRS-based system hadn’t hit production yet, so we had the freedom to pivot. But that's not always possible.

What this taught me is: always choose the simplest solution that solves the problem well. Start small, and optimize as you grow. Architecture is not about chasing trends — it’s about solving real problems with clarity and intent.

Let me know what you think about this one. Would love to hear your take — and also, if there’s a topic you’d like me to dive into next, feel free to drop it in!