[felixhuttmann]

Examples:

1) Long-living connections. One part of your application offers large file downloads, so that your users sometimes take significant amount of time to download, and the error rate shall be low. Think people doing `curl -L https://github.com/.../some-commit-hash.zip` in CI. I'd guess this is not served by github's ruby monolith. Or you use websockets. Redeployments typically stop all running tcp connections. Splitting this part off allows you to redeploy the main application frequently without disrupting websockets or downloads.

2) Reduce startup time. For some languages/ecosystems, startup time is significant and scales with the size of the codebase. For example, a typical java enterpise app like keycloak has half a million lines of code and takes about 1 minute only for startup. This is even more relevant when running things in AWS Lambda or google cloud run, and can also be relevant for integration tests. Having several deployables each handling a subset of the functionality may give you better cold start times than having one that contains all code.

3) Resiliency toward resource exhaustion. If two functionalities are served in the same process or VM, and one of them

* has a memory leak

* uses the connection pool to the database inefficiently and thereby clogs it up

* has an endpoint that is overloaded by a misbehaving client

then the other functionality is also affected, which can be avoided by putting them into separate processes/containers/VMs. Splitting services allows to reduce the effort spent on resource hygiene and rate limiting.

4) Binary size. It is often convenient to compile static info or asset-like things into the application, think geoinformation on timezones. This bloats the binary, splitting that part off into an independent deployable can give you a much smaller binary for the main application.

[eightysixfour]

1) Sure, that may be an example of a good microservice, but I'm not sure that is a requirement to follow a broad microservices architecture. This can also be handled via proxies/load balancers and rolling deployments of monoliths.

2) Agreed, for individual services. Maybe/maybe not for the entire system.

3) I think this is generally true, but if you have a service that others are dependent on, you can still have these problems. Auth services for example (that was a fun day at work).

4) Sure, but now you have two binaries.