Re:Decoupling a core service from your monolith the right way
by golemotron on Sunday June 04, 2023 @09:30AM
(#36185454)
Scaling and load balancing.
[ Parent
| on HN ]
Re:Decoupling a core service from your monolith the right way
by Berone on Sunday June 04, 2023 @09:38AM
(#36185510)
From a business perspective, unlocking this precision for infrastructure is only worth the investment at the highest levels of scale.
Re:Decoupling a core service from your monolith the right way
by treis on Sunday June 04, 2023 @09:56AM
(#36185642)
This is one of those things that was true in like 2008 but is no longer true in 2023. Scaling a monolith is slightly more expensive in memory consumption but in practice it's irrelevant for most cases.
In this particular case it's worse due to how Rails works. Usually people deploy one Rails thread per core and that core is blocked by the thread.
If that's the case when Service A calls Service B, Service A is blocking a core and waiting until Service B completes. That's effectively doubling resource consumption during that call. You have one server waiting on another server to do work it could have done itself.
Re:Decoupling a core service from your monolith the right way
by zrail on Sunday June 04, 2023 @12:01PM
(#36186650)
Ruby threads suspend on IO so a blocking HTTP request is very low cost.