What you'll learn
Quick Answer
A monolith is one deployable application; microservices are many small ones communicating over a network. Microservices solve organisational scaling, not technical elegance, and they add network failure, data consistency and operational complexity. Start with a monolith.
What each actually means
A monolith is one application deployed as a unit. Users, orders and payments may be separate modules, but they run in one process and share one database. A function call between them is a function call.
Microservices split those into independently deployable services, each typically owning its own database, communicating over HTTP or a message queue. That function call becomes a network request.
That last sentence is the entire trade-off. A function call cannot half-fail, arrive twice, or time out. A network request can do all three, and now your code must handle each case.
A monolith is not the same as badly-organised code. A well-structured monolith with clear module boundaries is a perfectly good architecture and is what most successful products run on for years.
What microservices actually cost
- The network is unreliable. Every call can fail, time out or arrive twice. You need retries, timeouts, and idempotency so a retried payment does not charge twice.
- Transactions across services are hard. In a monolith, deducting stock and recording an order is one database transaction — both happen or neither. Across two services with two databases, that guarantee is gone. You need patterns such as sagas with compensating actions, which are considerably more complex than a transaction.
- Debugging spans machines. One user action touches five services. Without distributed tracing and centralised logs, finding where it failed means reading five sets of logs.
- Local development gets harder. Running the system may mean running eight services and their databases.
- Operational overhead. Eight deploy pipelines, eight sets of monitoring, service discovery, and often Kubernetes — which is a substantial thing to learn and operate.
None of these are unsolvable. All of them are work that does not exist in a monolith, and none of them ship features.
So why does anyone do it?
The genuine reason is organisational, not technical, and this is the insight worth carrying into an interview.
With two hundred engineers on one codebase, the bottleneck stops being code and becomes coordination. Everyone waits on one deploy pipeline; one team's bad merge blocks everyone; releases need cross-team sign-off.
Splitting into services lets each team deploy independently, on its own schedule, without coordinating. That is worth a great deal at that scale, and it is worth nothing with four people.
Secondary reasons are real but narrower: scaling one component independently when it is genuinely the bottleneck, isolating failures so one broken service does not take the system down, and letting a specific service use a different language where that is justified.
Notice none of these apply to a project with three developers and a hundred users.
Start with a modular monolith
The widely-held current view — including from people who built large microservice systems — is to begin with a monolith and split later if a real reason appears.
The reason is that at the start you do not know where the boundaries are. Service boundaries are expensive to change, because moving a responsibility means moving data between databases and rewriting the calls. Module boundaries inside a monolith cost an afternoon.
So build a monolith with genuine internal structure: clear modules, one owning each area of data, communicating through defined interfaces rather than reaching into each other's tables. If a module later needs to become a service, the seam already exists.
Companies that split too early usually end up with a distributed monolith — services so interdependent that they must be deployed together. That has every cost of microservices and none of the benefits, and it is a common and expensive outcome.
How to handle this in interviews
Design questions often seem to invite microservices, and reaching for them immediately is a weaker answer than it appears.
A strong answer starts with scale. "For ten thousand users I'd build a well-structured monolith with a single database — it is simpler to operate and faster to change. If the notification component became a bottleneck, or if we had several teams needing independent deploys, I'd split that out first."
That demonstrates you understand the trade-off rather than the trend. Interviewers are frequently probing exactly this, because engineers who add complexity without a reason are expensive.
If asked directly about microservices, be able to name the hard parts — distributed transactions, network failure, tracing, data consistency — because knowing the costs is what distinguishes real understanding from having read an architecture diagram. See caching and API authentication for two areas that get noticeably harder once a system is distributed.