You’re not missing something. If you have a db it’s totally fine to protect invariants in the db. But there are cases where you don’t want to use the db (ephemeral data) or the db doesn’t scale well enough, so you e.g. shard access in the app layer. Those are the ones where additional processes can be quite useful. E.g. a few days ago I use a GenServer to act as a room for people to join via phoenix channels, which does only disappear after a certain timeout of nobody being connected. Sure I could’ve modeled this by putting information in the db and on channel connects see if the room is in the db and some “cron” like job to cleanup the db records after timeout, but it was way simpler to model as processes.

Building on what @LostKobrakai said - the best fit I’ve found so far for GenServers is for actions that need to happen spread out over time. (FWIW, the apps I work on haven’t reached the kind of scale that makes Postgres blink so I can’t speak to scaling advantages)

For instance, we use GenServers at work to track orders that are awaiting pickup by a courier and alert our support team if the pickup is late. In other languages, this might be done with a work queue / scheduler (think Resque / Sidekiq / etc) with a bunch of accounting to cancel the future job when the pickup happens. Using a GenServer (by way of GenStateMachine) makes the logic match the problem description, by using a state_timeout and transitioning on pickup.

Yes and no, they use case is completely different. GenServers are useful in cases where you need failure isolation.

Not Phoenix, but Cowboy which is underlying HTTP and WebSocket server.

If you use GenServer incorrectly it will be and bottleneck, but it has it’s use cases. For example imagine that you want to do background processing of data in a pool. Then you can use pool like poolboy and then each GenServer process will be responsible for one task. Other use case is when you want to provide simple cron-like features. Or you want to handle custom startup-shutdown features (for example connection draining). And so on. There is a lot of possible use cases outside of the REST-like HTTP connection handling.