Distributed systems are often presented as the holy grail of modern architecture. They are marketed with terms like "scalability," "flexibility," and "independence," which sound very appealing. However, my 20 years of experience have shown me that sometimes the simplest, most "old-fashioned" solution is actually the best.
Throughout my career, I have tried many different architectural approaches, both in my own side projects and in large-scale corporate projects. Sometimes, the biggest headaches came from the most "modern" and "distributed" architectures. This is my personal observation, and I want to explain why I still have a special fondness for centralized architectures.
The Dazzling Promises of Distributed Systems
At first, I too was captivated by the allure of distributed systems. The idea of breaking everything down into small, independent pieces seemed perfect in theory. Each service takes care of its own business, is deployed independently, and can be written in different technologies... These promises seemed like a salvation, especially for large and complex systems.
In particular, while working on a high-traffic e-commerce site, I saw how important modularity and independent scalability could be. Each microservice could scale on its own to handle different workloads, which positively impacted the overall system performance. However, there was another side to the coin.
The Real World and Hidden Costs
Apart from the promises, the chaos brought by distributed systems in the real world often outweighed their benefits. When designing an internal platform for a bank, the decision to switch to microservices was made. At first, everything was great, until a critical operation's transaction outbox mechanism blocked a workflow that involved three different services. The WAL rotation alarm that dropped at 03:14 that night taught me once again that the system is not just about code, but also about coordination, which has a real cost.
Debugging in distributed systems can be a nightmare. Following a request through multiple services makes it incredibly hard to track logs and find the root cause of errors. You need to put in a lot of effort for observability: metrics, logs, traces... Setting each of these up from scratch and making them meaningful is a project in itself. Adding network latency, serialization/deserialization costs, and eventual consistency problems, the overall complexity of the system multiplies.
⚠️ Experience Shows
The complexity of distributed systems often becomes an organizational barrier, not just a technical issue. The management of different services by different teams, communication gaps, and dependency management can become a bigger problem than the software architecture itself.
Last month, in the backend of my own side project, I encountered an OOM-killed situation caused by a simple sleep 360 command. At that moment, I realized that in a distributed system, even a single simple error can cause a chain reaction and tracking it down can be like finding a needle in a haystack. Eventually, I solved the issue by switching to polling-wait, but I saw once again how such "small" errors can have significant effects.
The Overlooked Power of Centralized Architectures
So, why are centralized architectures still valuable? The answer is simple: control and simplicity. In a production ERP system, we manage all purchasing, production, and shipping processes on a single PostgreSQL database and FastAPI backend. Initially, there were doubts about whether it would be monolithic. But five years later, the speed and consistency of managing complex production planning algorithms, iSCSI supply chain integrations, and operator screens in a single codebase became undeniable.
A single codebase accelerates the development process and simplifies debugging. Transactional integrity is much easier to achieve because the scope of database operations is clear. Yes, a monolith has a single deployment unit. But we minimized this risk with blue-green deployment and preferred simple database transactions over complex distributed transactions. Even when we encountered the N+1 problem in PostgreSQL, which we initially attributed to the ORM, we found it was actually due to the planner's optimization deficiency and solved it with a simple indexing strategy. Performing such in-depth optimizations in a single system is much easier.
When to Choose What? My Criteria
Of course, there is no one-size-fits-all solution for every situation. Architectural decisions are always about trade-offs. Based on my experience, I can summarize when I prefer centralized architectures and when I consider distributed systems:
-
When I Prefer Centralized Architectures:
- Complex Business Logic: When the workflow is tightly coupled and many components need to work consistently with each other.
- Small Team Size: For small and medium-sized teams, managing a single codebase is more efficient.
- Need for Rapid Iteration: When quick development and deployment of new features are necessary, the agility of centralized architectures stands out.
- Early-Stage Projects: In the initial stages of a product or project, avoiding unnecessary complexity is key.
-
When I Consider Distributed Systems:
- True High Scalability Needs: Scenarios that require extremely high traffic or data volume, where different parts need to scale independently.
- Independent Teams: Large organizations where each team is responsible for its own service and can make independent technology choices.
- Technological Diversity: Situations where different workloads genuinely require different programming languages or databases.
The choice of system architecture is a reflection of organizational flow and business requirements, rather than just software architecture. I have always tried to avoid over-engineering. Sometimes, the simplest, most well-known way to solve a problem is the best.
What was your most expensive architectural mistake, or what "old-fashioned" solution surprised you? I'd love to hear about it in the comments.
