> Serious question: why though? I can't think of a backend system where a single regression could bring the whole thing down. If something blows it up, it rarel

> Serious question: why though? I can't think of a backend system where a single regression could bring the whole thing down. If something blows it up, it rarely takes the whole application down. What's this scenario exactly? Maybe I'm only thinking of certain types of applications, but a single failure somewhere needn't bring the whole thing down. Suppose you have a web based CRUD that processes HTTP requests. To do this, it connects to a DB. There is one thread pool for HTTP requests, there's another thread pool for DB connections. Suppose there's an issue that causes a DB connection to hang (either a really slow query, or an issue with the DB thread pooling solution itself). All of the sudden, the DB thread pool is slowly getting exhausted, until no more queries can run because everything is hanging. Soon after, the HTTP request thread pool fills up, because requests are waiting for processing but none is being done. Users either see their requests frozen, or, if you're packaging both the API and the front end resources in the same deployment unit, soon nobody can even load the static resources of the page. I've seen this happen with a Java web app that used an old DB pooling solution that caused a prod outage years ago. Had to rip it out and replace it with something else. That said, the same could happen with stuff like scheduled processes conflicting, memory exhaustion, CPU utilization, disk usage and so on. Now, there shouldn't be anything preventing you from running multiple instances of monolithic codebases in parallel, though sometimes systems aren't written with that in mind (e.g. no DB queues/RabbitMQ for messaging/scheduled processes, no assumption of multiple instances accessing the same data, in-memory caches instead of Redis and so on) and you end up with a singleton application instead, which is worse than just a monolith. Either way, planning for components/systems failing and being able to recover from that is almost always a good idea (health checks, automated restarts, some horizontal scaling, uptime notifications and alerting, some instrumentation like APM), unless you're really short on time. None of that means that you should start with microservices though, unless your whole team is really comfortable with that. Monoliths are okay, as are modular monoliths (same codebase, deploy different features for app instances with feature flags, like FEATURE_ENABLE_API, FEATURE_ENABLE_SCHEDULED_PROCESSES etc.).