Exercises — Software architecture — layered, MVC, event-driven, microservices, serverless

• Layered → (b) technical concern by change-rate (UI vs business vs data).
• Microservices → (a) a business capability (Orders, Payments…), each with its own database.
• MVC → (c) three roles: Model (data), View (display), Controller (input-handling).

WHY: every style answers "how do we cut so a change stays local?" but they pick different cutting lines. Look at the figure: layered cuts horizontally (the stacked bands), microservices cut vertically (the standing columns, each with its own drum = database), and MVC splits a single box into three labelled roles. See Coupling and Cohesion.

Low coupling between modules; high cohesion inside a module. WHY: low coupling means changing module A rarely forces a change in B (they barely depend on each other). High cohesion means everything inside a module belongs together, so the module has one clear job.

False. Servers still exist; the cloud provider manages them, spinning them up on demand and down to zero when idle. You just never provision or patch them. See Cloud Computing — IaaS PaaS FaaS.

1. Controller — validates input, calls cart.addItem(). (Controller is the only piece touching raw input.)
2. Model — holds cart data + rule "max 20 items". (Business rules live in the Model.)
3. Controller — decides which page to show next. (Controller chooses what to show.)
4. View — renders updated cart HTML. (View decides how to show it.)

Order (with roles kept explicit, since two steps are the Controller): Controller (validate + update Model) → Model (apply rule) → Controller (choose which View) → View (render). Note the third step, "choose which View," is a Controller responsibility, not the View's — the View only knows how to render, never which page comes next. See Design Patterns — MVC, Observer.

Using $\text{direct}=n\cdot m$ and $\text{event-driven}=n+m$ with $n=4,m=6$:

• (a) direct $=4\times 6=24$ connections.
• (b) broker $=4+6=10$ connections (each side plugs once into the broker).

WHY it matters: direct wiring grows like $O(n\cdot m)$ — quadratic — while the broker grows like $O(n+m)$ — linear. Add a 7th consumer: direct jumps by 4 wires, broker by 1.

Edge / degenerate cases: if there are no producers ($n=0$) or no consumers ($m=0$), then both formulas give 0 connections — with nobody to wire, there is nothing to connect either way. The broker only starts winning once both sides have more than one participant; at $n=1,m=1$ direct needs $1$ wire and the broker needs $2$ (the broker adds one extra connection), so for tiny systems direct is actually cheaper. See Message Queues and Brokers.

GB-seconds per run $=0.5\times 0.4=0.2$ (memory × time, from the definition above). Compute cost = N \times 0.2 \times 0.00001667 = 2{,}000{,}000 \times 0.2 \times 0.00001667 = \6.668$.\ast \ast Requestcost\ast \ast$= 2{,}000{,}000 \times \dfrac{0.20}{1{,}000{,}000} = $0.40$.\ast \ast Total\ast \ast$\approx $6.668 + $0.40 = \boxed{$7.07}$ per month.

WHY so cheap: you pay only for the ~400{,}000 GB-seconds actually consumed ($2,000,000\times 0.2$). Idle time costs nothing — that is the serverless win when $N$ is bursty.

Layers separate concerns for maintainability, but the whole stack still usually deploys as one process (a monolith). To handle more load you must replicate the entire stack, not one layer — organizational separation is not deployment separation. Layers buy you reasoning locally and swappable implementations (change the DB without touching business logic), not raw horizontal scale. See Monolith vs Microservices and Scalability — Horizontal vs Vertical.

They removed spatial coupling — a producer no longer needs to know the consumer's address or wait for its response. They bought temporal complexity: Eventual Consistency (readers may see stale data briefly), no cross-service stack trace (harder debugging), and ordering / duplicate-delivery problems. Net: events trade "who-knows-whom" coupling for "when-does-it-actually-happen" uncertainty. Great for many independent reactions; painful for simple request→response.

The database row (shared → per-service) plus complexity in the network/ops. Splitting one shared DB into per-service databases forces distributed transactions and eventual consistency, and 5 engineers must now deploy/monitor N services over the network. For that team the code-level complexity of a monolith is far cheaper than the operational complexity of microservices.

• Synchronous (request path): charge the card. The customer must see success/failure now, so the Controller calls the payment step directly and waits.
• Publish OrderPlaced to a broker once payment succeeds.
• Event consumers (asynchronous): email receipt, decrement inventory, analytics — each subscribes to OrderPlaced. They can lag (eventual consistency is fine here).

WHY split this way: the fan-out is $1$ producer → $3$ consumers, so event-driven wiring is $1+3=4$ legs (one leg per participant, from the definition above) vs $1\times 3=3$ direct calls. Watch the overhead: here the broker path actually needs one more connection (4 legs vs 3 direct wires) — the extra leg is the producer→broker hop. In such a small case the broker is not cheaper on wire count; you choose it anyway because adding a 5th reaction (SMS) means adding one consumer and the order flow never changes. So the payoff is future changeability, not today's connection count. Correctness-critical steps stay synchronous; "fire-and-forget" reactions go async. See Message Queues and Brokers and Eventual Consistency.

Three microservices, one per team/capability (Payments, Search, Catalog), each owning its own database.

• Conway's Law: architecture mirrors the org, so mapping one service per autonomous team lets each ship independently. See Conway's Law.
• Independent scaling: only Search needs 10× replicas; a microservice split lets you scale it horizontally without paying to replicate Payments/Catalog. See Scalability — Horizontal vs Vertical.
• Cross-service events (e.g. ProductUpdated) keep Search's index fresh via a broker, accepting eventual consistency.

WHY not stay monolith: here the three drivers (independent deploy, independent scale of one hot capability, team autonomy) are all genuinely present — the exact conditions that justify the extra network/ops cost.

Serverless cost per invocation: $c=\underset{\text{compute}}{\underbrace{0.2\times 0.00001667}}+\underset{\text{request}}{\underbrace{\frac{0.20}{1,000,000}}}=3.334\times 10^{-6}+2\times 10^{-7}=3.534\times 10^{-6}\text{\$/call}.$ Set the two costs equal — serverless $N^{\ast }\cdot c$ must match the flat $150: $N^{\ast }\cdot c=150.$ Solve for $N^{\ast }$ by dividing both sides by $c$ (that isolates $N^{\ast }$, and the units check: \frac{\text{\}}{\text{$/call}} = \text{calls}): $$N^{*} = \frac{150}{c} = \frac{150\ \text{\}}{3.534\times10^{-6}\ \text{$/call}} \approx \mathbf{4.24 \times 10^{7}}\ \text{calls} \approx 42.4\ \text{million invocations/month}.$$

Reading it: below ~42M calls/month, serverless is cheaper (you pay near-zero when idle). Above it, the steady flat server wins. WHY: serverless cost is a straight line through the origin ($N\cdot c$); the server is a flat horizontal line (\150$).Theycrossexactlyonce,at$N^{*}$.

• Serverless: \text{Cost} = 0 \times c = \0$. Idle cost is exactly zero.
• Reserved server: still $150 — you pay 24/7 whether or not anything runs.

WHY this is the soul of serverless: most servers sit idle most of the time yet bill continuously. Serverless makes idle cost vanish, so it wins hardest for bursty / rarely-triggered workloads. The flip side: when load is huge and steady, that per-request fee accumulates past the flat server (Exercise 5.1), so serverless loses.

Strongest case for the monolith:

• One deploy unit and one database means no distributed transactions, no eventual-consistency bugs, and a real stack trace across the whole request — debugging stays cheap.
• Modular internal boundaries already give low coupling / high cohesion, so most maintainability benefits are had without the network cost.
• Fewer moving parts = lower operational cost (no N-service deploy/monitor pipeline).

The condition that flips it: when one module genuinely needs independent deployment or independent (horizontal) scaling that the shared process cannot provide — e.g. a hot Search path needing 10× replicas, or a team blocked because every release couples to everyone else's. Then, and only then, split that boundary out — start with the smallest split that relieves the real pressure. See Monolith vs Microservices.

A style that cuts along a business capability with its own database is ::: microservices. Direct wiring of $n$ producers to $m$ consumers scales like ::: $O(n\cdot m)$. Through a broker it scales like ::: $O(n+m)$. Serverless idle cost when $N=0$ is ::: exactly zero. Layers primarily improve ::: maintainability, not raw scalability.