Centralized routing: Pros and cons?

06 Tem 21:22

Last year, I decided to centralize my smart home systems, especially to control everything through a single hub. When I first set it up, it felt like something out of a fairy tale: wireless lights, thermostat, cameras—everything worked from one app. Then I met the infamous "single point of failure," I swear! One evening, the hub lost power, and my home turned back into a "dumb house." It took me three hours to plug in an Ethernet cable before even the simplest lamp would work. After that, I switched to a distributed system, connecting each device to its own Wi-Fi network or mesh. At first, inconsistencies annoyed me—lights would sometimes turn on late or miss voice commands. But after optimizing with mesh systems and locally running automations, I found that the flexibility and reliability of distributed systems were far more functional. Even though the cost was a bit high, the scalability and independence of each device meant my home kept running even in the worst internet outages. Now, instead of debating which architecture is better, I use both: critical devices are centralized, while the rest run on a distributed system.

06 Tem 22:46

The biggest drawback of centralized routing that I experienced firsthand in a project was the Single Point of Failure (SPOF) rumors. All traffic was routed through a single load balancer via an API gateway; when an AWS Availability Zone (AZ) went down, the system collapsed within 3-4 minutes, triggering a cascading failure with exponentially growing errors. After that incident, we switched to AWS Global Accelerator + Route 53 traffic policies at a 15% cost increase and mapped out a distributed architecture spanning over 2,000 regional endpoints. Simply put, users are now routed to the nearest entry point via CloudFront + Lambda@Edge, while each AZ has its own regional NAT gateway—so the failure of a single Availability Zone doesn’t bring down the entire system. The biggest nightmare I’ve faced in distributed systems is consistency. When sharding our MongoDB cluster, a 150ms delay between two shards caused stock updates to lag 2 seconds behind order creation, leading to double billing for orders. To fix this, we adopted the Raft consensus algorithm and required three-node approval for every write operation. While this increased costs by 8-10%, it allowed us to maintain 99.95% availability for over 1 million daily active users—a price worth paying. If your user base is only in the tens of thousands, a centralized Redis cluster with local caching might be a simpler and cheaper solution. Ultimately, prioritization depends on user experience: if you need low fault tolerance and global scale, distributed systems are a must. Otherwise, optimizing a centralized architecture is far smarter for smaller players.

06 Tem 23:25

I always get confused about database consistency in distributed systems, especially when trying to understand how multiple nodes synchronize without a central index.

06 Tem 23:57

I personally prefer distributed systems because they're more resilient to single points of failure and scalable. But you have to make a choice according to the CAP theorem for consistency issues; for instance, when choosing a database, you need to be flexible in terms of consistency and availability.

07 Tem 00:15

If you don’t want to deal with the headache of single-point failures, you’ll have to move to distributed systems. I used Kubernetes in my own projects; it seemed complicated at first, but StatefulSets and headless services helped me overcome consistency issues. Scaling is as simple as adding more nodes, even though the cost is a bit higher. But if your budget is tight and you can tolerate some errors, you could start with a centralized API gateway and transition to distributed systems later. For example, I tried Cloudflare Workers first before moving to my own cluster setup. When making decisions, AWS’s "Well-Architected" framework was a huge help—you should definitely check it out.