Phoenix is practically built with this idea in mind.

My startup is built out of a single phoenix monolith. Only external dependency is postgres.

Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said service and error handling in the event of a crash.

I'm basicly getting all the best advantages of a monolith

* one codebase to navigate, our team is TINY * all functionality is in libraries

And all the advantages of microservices without the associated costs. (orchestration, management etc)

* bottleneck use cases can live on their own nodes

* publish subscribe to dispatch background jobs

* services that each focus on doing one thing really well

We've accomplished this all through just libraries and a little bit of configuration. At no point so far have we had to..

* setup a message broker (phoenix pubsub has been fine for us. we can send messages between different processes on the server and to the clients themselves over channels)

* setup external clusters for background workers. (Oban was drop in and jsut works. I'm able to add a new worker without having to tell devops anything. the supervision tree allocates the memory for the process and takes care of fault tolerance for me. That leaves me to focus on solving the business problems)

* setup a second github repo. Its a monorepo and at out scale, its fine. We have one library for communicating to the database that every system just uses.

Eventually we'll probably have to start rethinking and building out separate services. But I'm happy that we're already able to get some of teh benefits of a microservice architecture while sticking to what makes monoliths great for mvps. It will be awhile before we need to think about scaling out web service. It just works. Leaves me more time to work on tuning out database to keep up!