Learning objectives
- When would you recommend a modular monolith to an enterprise customer?
- How would you budget latency across an API gateway and three services?
- Apply Dependency graph to a customer decision and defend the tradeoff.
The mental model
An architecture diagram should explain who owns data, which calls are required for a user action, and what happens when a dependency fails. A monolith can be reliable and easy to operate; a collection of microservices can be tightly coupled despite having many repositories. Service boundaries should follow meaningful ownership and change patterns. An API gateway provides an entry point for routing and shared policies, but it cannot repair unclear domain boundaries. Serverless changes how execution is provided, not the need to design state, timeouts, and permissions. Start from the customer's team and workload rather than a preferred architectural fashion.
How it works
Model a critical workflow as a directed dependency graph. For a synchronous chain, each required downstream service contributes latency and can prevent completion. Parallel calls may reduce elapsed time but increase load and complicate partial failures. Set a total request deadline and allocate downstream budgets so a child call cannot consume all available time. Include connection setup, retries, and response processing in the budget.
Choose a monolith when cohesive changes and shared transactions dominate and the team benefits from one operational unit. Split a service when independent ownership, deployment cadence, security isolation, or scaling justifies network and consistency costs. An API gateway may centralize authentication checks, rate policy, and routing, but domain authorization remains with the responsible application boundary. Serverless functions should have explicit persistence and dependency contracts; process-local state is not a durable business record. Document the control plane separately from the data plane. For a compiler service, building artifacts, scheduling work, and retrieving results have different scaling and trust requirements even if the first version deploys them together.
A simple boundary exercise is to remove one component from the diagram and ask which customer workflow stops. If every service depends synchronously on every other service, the diagram may reveal a distributed monolith. If a reporting component can fail while order creation continues, its boundary provides useful isolation. Document whether the separation is achieved through asynchronous data transfer, a cached view, or an explicit degraded state; otherwise the claimed independence may be only visual.
Applied example · hypothetical
Hypothetical scenario: a founder wants to split a quote application into twelve services because enterprise prospects expect scale. You map the quote approval workflow and discover that most changes touch pricing, approvals, and audit history together. A modular monolith preserves a useful transaction boundary. Document rendering is the first separation candidate because it is slow, independently retryable, and resource intensive. The recommendation includes a queue boundary and a versioned event contract. Scaling benefits remain hypotheses until a representative workload demonstrates them.
In a customer engagement
Ask the customer which releases are blocked, which component saturates first, and which teams can own independent operations. Use their most valuable workflow as the diagram's center. Present a conservative baseline alongside a distributed alternative, then explain the additional deployment, observability, and consistency responsibilities required by the second option before estimating its benefit.
Interview relevance
In an interview, resist answering microservices versus monoliths as a belief statement. Define the workload and organization, state a provisional choice, and explain what evidence would change it. Your experience with applications, compilers, and orchestration can supply real boundary decisions, but do not attach invented scale or revenue figures to those examples.
Common mistakes
- Equating microservices with maturity
- Ignoring operational capacity
- Giving every child the full request timeout
Key terminology
Dependency graph — A representation of the components and calls required to complete an operation.
Deadline budget — The maximum elapsed time allocated across a request and its downstream work.
Domain boundary — A division of business responsibility that clarifies ownership of rules and data.
Explain it without the page
- When would you recommend a modular monolith to an enterprise customer?
- How would you budget latency across an API gateway and three services?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.