Monolith

A monolith means all business logic (users, courses, payments, notifications) is built into one process. It is built and deployed together: one Docker image, one git push, one version in production.

It does not mean «one server». A monolith usually runs as several identical copies behind a load balancer, all talking to one database. Scaling is horizontal, each copy just knows how to do everything.

ShortLesson started exactly like this: a Next.js app that serves pages, the mobile API and the admin panel, plus one PostgreSQL. For thousands of users that is more than enough.

A call between modules inside one process costs nanoseconds, while a network call between services in the same data center is usually 0.5 to 2 ms plus serialization. If a request touches five modules, in a monolith you will not notice, in microservices it is real milliseconds and five points of failure.

Transactions are simple too: placing an order, charging the balance and recording an event can happen in one PostgreSQL transaction. No sagas, no compensations, no eventual consistency.

The pain rarely comes from load, it comes from people. When 30 to 50 engineers work in one repository, the build takes 20 minutes, tests fail because of someone else's change, and one team's release blocks everyone.

The second problem is blurred boundaries. Without discipline any module reads any table, and the monolith becomes a «big ball of mud». The cure is a modular monolith, not necessarily a move to microservices.

First add copies of the app behind a load balancer and move sessions out of process memory (into a cookie, a JWT or Redis). Next come a cache for hot reads and read replicas of the database.

Heavy jobs (video transcoding, mailings, reports) move to background workers with a queue, but the worker code can stay in the same codebase. In 2016 Stack Overflow served millions of requests a day with a monolithic .NET application on nine web servers.