Module F-7·16 min read

Why the monolith is almost always the right first answer, what a tier really buys you, and how layer boundaries decay when nobody defends them.

JJS

Written by Jatin Jain Saraf · Senior Software Engineer

Module F-7 — Client–Server, N-Tier, and the Monolith

Q: A checkout endpoint accepts `{ productId, quantity, price }` from the client and creates an order using the submitted `price`. The team argues this is safe because the UI always sends the correct price from the product page. What's the assessment?

It's a broken trust boundary: anything a client sends is a claim, so price must be looked up server-side from the product record. Client-side correctness is a UX property, not a security control — `curl` bypasses the UI entirely. — The module states the rule directly: the trust boundary is the server, every client byte is hostile until validated, and prices, totals, discounts, and permissions must be computed server-side. It calls the client-supplied-price bug the oldest bug in e-commerce and notes that it still ships. Option A misunderstands what TLS protects — it secures the channel against third parties, and does nothing about a legitimate client choosing to send `price: 1`. Option B confuses obscurity with control; a native client is still a client, and its traffic is trivially interceptable. Option C assumes a later check that the described design doesn't have, and the module's broader point is that this belongs at the boundary in one place, not scattered across downstream steps hoping one catches it.

Q: A four-person team is starting a new product and debating microservices versus a monolith. Which reason does the module present as the *strongest* argument for starting monolithic?

You don't yet know where the service boundaries belong — boundaries encode which things change together, and early on that guess is wrong. A wrong boundary inside a monolith is a refactor; between services it's a migration with cross-team coordination. — The module lists several genuine benefits — working transactions, compiler-checked refactoring, one place to look, no internal network — and then singles out boundary uncertainty as "the strongest argument," precisely because it's the one that can't be recovered from cheaply. The asymmetry is the point: refactoring a bad module boundary is an afternoon; re-drawing a service boundary is a migration involving other teams and deployed contracts. Options B, C, and D are all real advantages the module mentions or implies, but each is a matter of degree that a well-resourced team could accept or offset. Only option D is about foreclosing a decision you're not yet equipped to make.

Q: A team adopts a modular monolith: each module owns its tables and exposes a narrow public interface, so `orders` calls `inventory`'s interface rather than joining its tables. What does the module say about this trade?

It's a real cost — foregone joins, extra indirection, sometimes duplicated data — paid for the option to extract a service later, so it's worth adopting where you already suspect a seam rather than uniformly. — The module states the trade-off explicitly: you pay foregone joins, extra indirection, and occasional duplicated data in exchange for optionality you may never use, and it concludes that plain clean layering is enough for a small product with a stable team — adopt module boundaries where you suspect a seam, not everywhere. Option A drops the cost half of the sentence, which is the pattern this course is written against. Option C gets it backwards: the discipline of not assuming a shared transaction is what makes extraction *possible*, but once split you will need sagas or an outbox (Module A-3) — the interfaces provide no atomicity across a network. Option D overstates the equivalence; the split still means dealing with partial failure, retries, timeouts, and independent versioning, which the module describes as the actual work that remains.

What this module covers: The shape of the application behind the wire. This module covers the client–server model and where the trust boundary actually sits, what a tier buys you that a layer doesn't, how to structure a monolith so its layers survive contact with deadlines, and the modular monolith as the design that gets you most of what people want from microservices without a distributed system. It makes the case that the monolith is almost always the correct first answer — and then names its costs honestly, along with the specific signals that mean it's time to split.

Layers and Tiers Are Different Things

These get used interchangeably and shouldn't be.

A layer is a logical separation inside one codebase: HTTP handlers call services, services call repositories, repositories talk to the database. It's an organisational boundary enforced by discipline and tooling.

A tier is a physical separation: a separate process, on a separate machine, reachable over a network. It's enforced by the network itself.

The classic three-tier architecture has a presentation tier (web server), an application tier (business logic), and a data tier (database) as three deployable units. A well-structured monolith has the same three layers in one deployable unit.

The distinction matters because a tier boundary is a network call, and a network call is a failure mode. Converting a layer into a tier buys you independent scaling, an independent security boundary, and independent technology choice. It costs you serialisation, network latency, partial failure, and a distributed debugging problem. Every module in Phase 3 of this course is, in some sense, the bill for that conversion.

Analogy: layers are rooms in a house; tiers are separate buildings. Rooms give you organisation for free — a wall is cheap, and walking between rooms costs nothing. Separate buildings give you real isolation (one can burn down without the other) but now everything is a trip outside, in the weather, and sometimes the road is closed.

Client–Server, and Where Trust Actually Ends

The model is one line: a client sends a request, a server processes it and responds. The client holds no authority.

That last part is the whole of it, and it's the part that gets violated. The trust boundary is the server, and every byte that crosses it from a client is hostile until validated. Consequences that are still routinely got wrong:

Validation on the client is a UX feature, not a security control. Anything enforced only in the browser or app is unenforced. curl exists.
Prices, totals, discounts, and permissions must be computed server-side. A client that sends { productId, price: 1 } and gets charged $1 is the oldest bug in e-commerce, and it still ships.
IDs from a client are a claim, not a fact. GET /api/orders/8241 must verify that the authenticated user owns order 8241. Skipping that is IDOR — a broken-access-control vulnerability, and consistently one of the most common serious findings in real applications (Module A-13).

Why this matters in production: every one of these is invisible in testing, because your test client is well-behaved. They surface as a security report, not a bug report — and the fix is architectural (validate at the boundary, always, in one place) rather than a patch at each call site.

Why the Monolith Is the Right First Answer

A monolith is one deployable unit containing all the application's logic. Not one file, not one giant function — one deployable.

The argument for starting here isn't nostalgia; it's that a monolith gives you several things for free that a distributed system makes into projects:

Transactions actually work. Updating an order and decrementing inventory in one ACID transaction is a BEGIN/COMMIT. Split those across two services and you need sagas, compensation, and an outbox — Module A-3, and it is genuinely hard.
Refactoring is safe. Rename a function and the compiler finds every caller. Rename a field in an API contract between two services and you find the callers in production.
One place to look. One log stream, one stack trace, one deploy, one version. Distributed tracing (Module O-1) exists to recover in a distributed system what a monolith gives you by default.
No network between your own components. No serialisation cost, no partial failure, no retry logic, no circuit breaker, no timeout tuning between your own modules.
You don't know the boundaries yet. This is the strongest argument. Service boundaries encode assumptions about which things change together, and early on you're wrong about that. A wrong boundary inside a monolith is a refactor; a wrong boundary between services is a migration with a coordination cost across teams.

And the honest costs, which are real:

One deploy for everything. A risky change to reporting ships alongside checkout. Mitigated substantially by feature flags and canary deploys (Module O-4), not eliminated.
Scaling is all-or-nothing. If image processing needs CPU, you scale the whole application to get it. Wasteful, though often cheaper than the alternative until the waste is large.
One runtime, one language. No dropping into Rust for the hot path or Python for the ML piece without a separate process.
Blast radius. A memory leak in a rarely-used admin endpoint can take down checkout, because it's the same process.
Coordination cost grows with team size. At some headcount, everyone editing one codebase and one deploy pipeline becomes the bottleneck. This is a genuine limit, and it's about organisation, not technology.

Note that the costs are mostly about scale — of traffic, of team, of divergent requirements. Which is why the recommendation isn't "monoliths are better," it's "start with a monolith and split when a specific, named signal appears" (Module A-4 covers those signals in depth).

Structuring a Monolith So It Stays Structured

An unstructured monolith earns every bad thing said about the pattern. The structure that holds up is layers with dependencies pointing one direction only.

text

src/
  http/            ← HTTP concerns ONLY: parsing, validation, status codes
    routes/
    middleware/
  domain/          ← business logic. Knows nothing about HTTP or SQL.
    orders/
      order.ts             (entity + invariants)
      order-service.ts     (use cases)
      order-repository.ts  (INTERFACE, not implementation)
    inventory/
    payments/
  infrastructure/  ← implementations of domain interfaces
    postgres/
      order-repository.ts  (implements the domain's interface)
    redis/
    email/

The rule: http may depend on domain; infrastructure may depend on domain; domain depends on nothing. The domain layer is where your actual business rules live, and it should be testable without a database, an HTTP server, or a network.

typescript

// domain/orders/order-repository.ts — the domain states what it needs.
export interface OrderRepository {
  findById(id: OrderId): Promise<Order | null>;
  save(order: Order): Promise<void>;
}

// domain/orders/order-service.ts — pure business logic, no infrastructure.
export class OrderService {
  constructor(
    private readonly orders: OrderRepository,
    private readonly inventory: InventoryRepository,
  ) {}

  async cancel(id: OrderId, actor: UserId): Promise<Order> {
    const order = await this.orders.findById(id);
    if (!order) throw new NotFoundError('order', id);
    if (!order.canBeCancelledBy(actor)) throw new ForbiddenError();

    order.cancel();                      // invariants enforced on the entity
    await this.inventory.release(order.lines);
    await this.orders.save(order);
    return order;
  }
}

// http/routes/orders.ts — HTTP translation only. No business rules here.
router.post('/orders/:id/cancel', async (req, res) => {
  const order = await orderService.cancel(
    OrderId.parse(req.params.id),
    req.auth.userId,                     // from the verified token, never the body
  );
  res.json(toOrderResponse(order));
});

Two details in that snippet carry most of the value. The actor comes from req.auth, never from the request body — the client–server trust rule, enforced structurally. And canBeCancelledBy lives on the entity, so the rule can't be forgotten by a second caller; a new GraphQL resolver or background job calling cancel() gets the same check for free.

How this decays, in the order it usually happens:

A route handler runs a query directly — "just this once, it's a simple lookup." Now business logic exists in the HTTP layer, and the next caller can't reuse it.
A utils/ folder appears with no ownership and becomes a dependency of everything, so nothing can be moved.
The ORM's model objects get returned straight to HTTP responses. Now your API contract is your database schema, and a column rename is a breaking API change.
Circular imports appear between domain modules. Now nothing can be extracted, and the option to split later has quietly been spent.

The countermeasure is boring and effective: enforce the boundaries in CI. ESLint's no-restricted-imports (or dependency-cruiser) can fail the build when domain/** imports from infrastructure/**. A rule nobody can quietly ignore is worth ten pages of architecture documentation.

The Modular Monolith

The modular monolith is the design that gets most of the benefit people actually want from microservices, without the distributed system. One deployable unit, but internally divided into modules with explicit, enforced interfaces between them.

The rules that make it real:

Each module owns its data. orders does not query inventory's tables. If it needs inventory data it calls inventory's public interface — even though a join would work and be faster.
Each module has a deliberate public surface, with everything else internal. In TypeScript, one index.ts per module exporting only the contract.
Cross-module calls are function calls today, and could become network calls tomorrow. Which means: no shared mutable objects across the boundary, and no assumption of a shared transaction (this is the discipline that makes extraction feasible later).

What this buys: when you eventually need to extract payments into its own service, the seam already exists. The work becomes "replace an in-process call with an HTTP call and deal with the failure modes," not "untangle four years of intertwined code."

Trade-off, stated: you're paying real cost — foregone joins, extra indirection, occasional duplicated data across modules — for optionality you may never exercise. That's a genuine cost, and it's worth it only if you have concrete reason to think a split is coming. For a small product with a stable team, plain clean layering is enough, and enforced module boundaries can be over-engineering. The honest version is: adopt modular boundaries where you already suspect a seam, not uniformly.

Where This Shows Up in Your Stack

Next.js: the App Router bakes the client–server boundary into the file system — Server Components and Route Handlers are server-side, everything in a 'use client' component is shipped to the browser. The trust rule applies with a sharp edge: an environment variable prefixed NEXT_PUBLIC_ is in the bundle, and secrets have leaked that way in real applications.
PostgreSQL: the data tier is nearly always a separate tier out of necessity — durability, backups, and independent scaling — which is why every module from P-4 onward is about the consequences of talking to it over a network.
Node.js: a single-process monolith means one event loop. A CPU-heavy operation in any part of the application blocks all of it (Module F-4). Worker threads or a separate service are the answers, and this specific limitation is one of the more legitimate reasons a Node monolith gets split early.
Serverless: deploying a monolith as one function per route gives you a single codebase with independently-scaling entry points — genuinely a middle ground. The trade-off is Module F-10's list: no shared in-process state, no background work after the response, and a connection-pooling problem at the database (Module P-4).

Summary

Layers are logical, tiers are physical. A tier boundary is a network call, which means a failure mode; converting a layer into a tier buys independent scaling and isolation, and costs serialisation, latency, and partial failure.
The client is never trusted. Client-side validation is UX; prices, permissions, and ownership checks are computed server-side, and an ID from a client is a claim to verify.
Start with a monolith. Transactions work, refactoring is compiler-checked, there's one place to look, and — most importantly — you don't yet know where the service boundaries belong.
Name the monolith's costs: coupled deploys, all-or-nothing scaling, one runtime, shared blast radius, and coordination cost that grows with team size.
Structure it with one-directional dependencies: http → domain ← infrastructure, with the domain layer knowing nothing about either. Enforce it in CI, because discipline alone doesn't survive deadlines.
Watch the four decay patterns: queries in handlers, an unowned utils/, ORM models as API responses, and circular imports between domain modules.
A modular monolith preserves the option to split by making modules own their data and expose explicit interfaces — at the real cost of foregone joins and extra indirection, so apply it where you suspect a seam rather than everywhere.

The next module, API Design: REST, GraphQL, and gRPC, takes the boundary you've just drawn and asks what should cross it — resource modelling, versioning, pagination that survives page 900, and the N+1 problem in its API-layer disguise.

Knowledge Check

A checkout endpoint accepts { productId, quantity, price } from the client and creates an order using the submitted price. The team argues this is safe because the UI always sends the correct price from the product page. What's the assessment?

A four-person team is starting a new product and debating microservices versus a monolith. Which reason does the module present as the *strongest* argument for starting monolithic?

A team adopts a modular monolith: each module owns its tables and exposes a narrow public interface, so orders calls inventory's interface rather than joining its tables. What does the module say about this trade?

Test your knowledge with more question sets

Sign in to keep reading

The rest of this module is free — sign in with Google to unlock it and track your progress.

PreviousModule F-6: HTTP/1.1, HTTP/2, and HTTP/3 Next Module F-8: API Design: REST, GraphQL, and gRPC

Discussion

Join the discussion

Loading comments...