Monolith vs microservices vs serverless

A monolith is the cheapest to start: a few VPS or containers and one database, all run by one or two engineers. Microservices are almost always more expensive: each service has its own copies, database and monitoring, plus you need Kubernetes, a broker and tracing. Serverless costs nearly nothing at low traffic, but under steady high load it often becomes the most expensive.

For team size, a rough guide: a monolith is comfortable up to 10 or 15 engineers, a modular monolith up to a few dozen, and microservices pay off when there are many teams, each owning its domain. Serverless is especially good for small teams without DevOps.

A monolith deploys as a whole: a simple pipeline, but all releases go in one stream. Microservices deploy independently, dozens of times a day, but need CI/CD per service and contract tests between them. In serverless, deploying one function takes seconds.

A monolith scales by copying the whole application. Microservices scale only the hot services. Serverless scales automatically per invocation, from zero to thousands of parallel executions, but with concurrency limits and cold starts.

A monolith has one database and ACID transactions. In microservices and serverless data is spread across stores, so consistency becomes eventual, with sagas and idempotency.

Debugging a monolith: one process, one call stack, a breakpoint in the IDE. In microservices, without distributed tracing, finding the cause of an error is very hard. Serverless adds the difficulty of reproducing events locally.

Latency: a call inside a process costs nanoseconds, a network call between services about 1 ms within a data center, a function cold start from tens of milliseconds to a second. A chain of 5 network calls easily adds 10 to 30 ms to a response.

Start with a modular monolith: one deploy, clear modules, separate data schemas. It is the cheapest way to learn where the real domain boundaries are.

Extract a module into a service when there is a concrete reason: a separate team keeps getting blocked by the shared release, the module has very different load or availability needs, or it needs a different technology. Do not split «for future growth».

Use serverless selectively for spiky and event workloads: processing uploaded files, webhooks, cron, uneven APIs. This way ShortLesson can keep its main app in a container and hand video transcoding to functions.