Microservices vs Monolith

Question 1

In a monolithic architecture, a critical bug is introduced in the Notifications module. Which best describes the likely impact at runtime?

Accepted Answer

The entire application process can crash, making Auth, Orders, Payments, and Inventory unavailable too. — All modules in a monolith run inside the same process. An unhandled exception or OOM in one module can kill the whole process — a pattern called shared-fate failure. There is no in-process boundary that prevents a crash in one area from propagating to the others.

Question 2

Your team wants to update only the Payments service without restarting any other part of the system. Which architecture makes this straightforward?

Accepted Answer

Microservices, because each service is a separate deployable artifact and can be released independently. — Independent deployability is a core benefit of microservices. In a monolith every change — however small — requires recompiling and redeploying the entire application, which increases deployment risk and forces coordination across teams. Microservices let the Payments team ship on their own schedule.

Question 3

A social platform uses microservices. The Notifications service goes down. Users cannot receive push alerts, but they can still log in, browse, and post. What architectural property explains this?

Accepted Answer

Fault isolation — each service fails independently rather than spreading failure system-wide. — Fault isolation means a failure in one service does not cascade to others. Because Auth, Feed, and Posts run in separate processes with separate resources, the Notifications outage is contained. This is in sharp contrast to a shared-fate monolith where the same crash would make the whole product unavailable.

Question 4

In a microservices architecture, Service A calls Service B, which calls Service C to complete a single user request. What cost is paid that does not exist in a monolith?

Accepted Answer

Network latency and serialization overhead on each inter-service call. — In a monolith, module-to-module calls are in-process function calls — effectively free. In microservices every cross-service call crosses a network boundary, adding latency (often 1–5 ms per hop) plus serialization/deserialization cost. Deep call chains can make p99 latency significantly worse than the monolith equivalent.

Question 5

A startup has 3 engineers and is building its first product. Which architecture is generally the better starting point and why?

Accepted Answer

Monolith, because a small team cannot yet afford the per-service overhead of separate pipelines, distributed tracing, and on-call rotations. — Small teams pay a disproportionate operational tax for microservices: separate CI/CD pipelines, distributed tracing, service discovery, health checks, and on-call burden multiply with each service. A monolith lets a tiny team move fast with low overhead. Martin Fowler calls this the "Monolith First" pattern — extract services only when pain points become concrete.

Question 6

The Orders service and the Inventory service each own their own database. A user places an order that requires decrementing inventory. How should this cross-service data change be coordinated?

Accepted Answer

Use a Saga or outbox pattern, where each service does its local transaction and publishes an event; compensating transactions handle failures. — Distributed ACID transactions (2PC) are available but brittle and a scalability bottleneck. The standard microservices pattern is the Saga: each service does its local transaction and publishes an event; other services react to that event and roll back compensating transactions on failure. This keeps services loosely coupled while preserving data correctness over time.

Question 7

Which of the following is the most principled way to define the boundary of a microservice?

Accepted Answer

Split by business capability: group together the data and logic that belongs to one cohesive business function. — Domain-driven design recommends aligning service boundaries with bounded contexts — cohesive business capabilities like "Order Management" or "Identity." Splitting by technical layer (e.g., a "database service") creates chatty, tightly coupled services that defeat the purpose of decomposition. Size heuristics and team headcount are secondary heuristics, not the primary design driver.

Question 8

You need to scale the Payments service to handle Black Friday traffic without over-provisioning the other services. Which architecture allows this directly?

Accepted Answer

Microservices, because each service can be scaled out independently based on its own traffic metrics and resource constraints. — Independent scalability is a key microservices advantage. You can run 20 Payments replicas and 2 Notifications replicas simultaneously. In a monolith you must scale the entire application even if only one module is under load, wasting resources and increasing cost. Kubernetes can help, but the services must be separate deployable units to get per-module scaling.

Question 9

A team migrating from a monolith extracts the Auth module into its own service, but every API request now has ~15 ms higher latency. What is the most likely root cause?

Accepted Answer

Each request now crosses a network boundary to Auth for token validation, adding several milliseconds where there was previously just a function call. — What was previously an in-process function call (nanoseconds) is now a synchronous HTTP or gRPC call across the network (milliseconds). Multiplied across every authenticated request, this adds up quickly. Common mitigations include JWT validation at the gateway (so Auth is not called per-request), caching auth decisions, or using async validation patterns.

Question 10

A monolith deployment takes 45 minutes and is performed once a month because it is risky. A microservices team deploys individual services dozens of times per day. What architectural property primarily enables the microservices team's higher deployment frequency?

Accepted Answer

Each deployment has a smaller blast radius — a broken release takes down one service at most, so teams deploy more confidently and more often. — When a deployment can only fail one service at a time, teams are willing to deploy more frequently. The smaller blast radius reduces fear. In a monolith, every deployment risks the entire product, so teams batch changes and deploy infrequently — which ironically makes each deployment riskier because the diff is larger.

Architecture Comparison

Monolith or microservices?

Test your knowledge

In a monolithic architecture, a critical bug is introduced in the Notifications module. Which best describes the likely impact at runtime?

The short version

Interview Questions

References & Further Reading

Related topics

Love this visualization?