Microservices vs Monolith

A monolith is one deployable unit: one codebase, one process, one thing to run and test. Microservices split the system into independently deployed services that talk over the network. The animation shows exactly what you buy — and what you pay — when you split.

It opens with one large block cleaving along dotted feature lines into separate services — upload, encoding, search — connected by thin network wires. Then the payoff moment: a traffic surge hits, and only the video-encoding service inflates into five replicas while the others stay small. That is the honest argument for microservices: independent scaling. In the monolith, you would have had to clone the entire application five times to scale one hot function.

Then watch the price. One wire between services flickers — a network call failing. Inside a monolith that call was a function call that could not fail on its own; now it is a partial failure you must handle with timeouts, retries, and fallbacks.

Carry this into interviews: draw separate logical services only when you can justify each one ("booking is separate because it needs strong consistency and independent scaling from search"). Cargo-culting a dozen boxes reads worse than a well-defended monolith — for most products, monolith-first is the right call.