Hacker News Reader

Comment by lolinder | Hacker News Reader

One that I don't think a monolith can solve is partial availability.

A monolith is either available or it isn't, which is fine as long as you can guarantee that nothing ever takes down the monolith, but we all know that that's not something you can guarantee.

If you split out services that live outside the critical path, then when those services go down you can still engineer your system to keep going and gracefully degrade the functionality provided by those currently-down services.

This makes incident response much less stressful because there's less urgency, which in turn leads to fewer mistakes during the response and faster recovery times.

(Yes, there are some pieces of functionality that will always be in the critical path, like authorization, but many things don't have to be.)

View on HN

This is why I like having things split up. Even with zero service redundancy, it massively improves the reliability of the system overall. Often users don't even notice that a less important service had to restart because of an issue. If that service was just another component of a monolith, then it failing would guarantee that the whole monolith fails.

In my experience you’ll be fine with monolith instances and failover. Probably until you’re Google scale

Monolith plus failover gets you better availability, not partial availability. Code errors or network problems or many other types of errors can still take down both the main instance and failover unless you're perfect at preventing them, and when that happens you have zero availability until you fix it.

Not really. Even with a monolith, you get partial availability. Most often as a default.

Imagine a web server handling requests. It usually has a way to recover from a crashed request handler. On top of that, you have multiple web servers behind a load balancer. Some code paths may be failing, some may be available.

Then, you have some background workers, maybe ingesting data from third party services. They're completely different processes from your web servers, even though they still use the monolithic code base. If they're down, the web app can still work with stale data.

The partial availability can be compromised in microservices as well as in a monolith (e.g. auth as you mentioned).

> Imagine a web server handling requests. It usually has a way to recover from a crashed request handler. On top of that, you have multiple web servers behind a load balancer. Some code paths may be failing, some may be available.

This is a form of partial availability but not what I'm talking about. I'm talking about a scenario where a DoS attack or an initialization error or an external service timing out causes the entire service (all instances) to fail to respond to any requests. Past a certain scale of app these things do happen periodically, and if you've split out non-critical code into separate services and handled for graceful degradation that code can no longer bring down the critical paths.

> They're completely different processes from your web servers, even though they still use the monolithic code base.

I... wouldn't call these part of a monolith, though they're not exactly microservices either. They're separately deployed units of code that happen to exist in a monorepo. This gives them similar resilience characteristics to microservices, so they're not a counterexample, they're more of a subcategory of what I'm talking about.

> The partial availability can be compromised in microservices as well as in a monolith (e.g. auth as you mentioned).

This is the "but sometimes" fallacy. If solution B allows for graceful degradation 80% more often than solution A, it's still better at graceful degradation even if it doesn't reach 100% success.

Reply on news.ycombinator.com