Software architecture — layered, MVC, event-driven, microservices, serverless: Visual walkthrough

Parent: 4.5.05 Software architecture — layered, MVC, event-driven, microservices, serverless (Hinglish)

Step 1 — Two boxes and one wire (what "coupling" even means)

WHAT. Draw the smallest possible system: two pieces of code, A and B. A needs something from B, so we draw an arrow from A to B. That arrow is a dependency: A knows B exists, knows how to call it, and breaks if B changes.

WHY. Before any fancy style, we must name the thing we are fighting. That arrow is the unit of coupling. Architecture is the art of controlling arrows — how many there are and which direction they point.

PICTURE. Look at the single orange arrow. If it points both ways (A needs B and B needs A), that is a cycle — the worst case, because you cannot understand or test either box alone.

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

Step 2 — The explosion: n producers, m consumers

WHAT. Now grow the picture. Suppose we have $n$ pieces that produce work (call them producers) and $m$ pieces that consume it. In the naive design, every producer calls every consumer it needs directly.

WHY. This is the moment coupling gets dangerous. When each of the $n$ boxes may talk to each of the $m$ boxes, the number of wires is the product.

PICTURE. Count the arrows in the left panel. With $n = 3$ and $m = 3$ you can see $9$ arrows crossing in a mesh.

Step 3 — First cut: impose a direction (layered)

WHAT. The first cheap fix is not to remove arrows but to forbid most of them. Stack the boxes into horizontal layers and pass one rule: an arrow may only point straight down to the layer directly below. No skipping, no pointing up, no sideways.

WHY. Different layers change at different speeds — the screen changes weekly, the database yearly. By allowing only downward arrows, a change on top can never ripple upward. We turned a tangled mesh into a one-directional stack.

PICTURE. Notice every arrow now points down and there are no cycles. The count collapses from a mesh to a straight line: $4$ layers need only $3$ arrows.

Step 4 — The special case of the UI: MVC

WHAT. Zoom into the top layer, where a human clicks. Split it into three roles arranged in a triangle: Model (the data + rules), View (draws the data), Controller (catches the click, updates the Model, picks the View).

WHY. The same data may be shown many ways — a table, a chart, a JSON feed. If drawing code and data code are one blob, you cannot reuse the data. MVC pins the Model as the single truth and lets Views be swapped freely.

PICTURE. Follow the numbered arrows: click → Controller (1), Controller updates → Model (2), Model notifies / Controller selects → View (3), View reads Model → screen (4). The Model never reaches back to grab the screen — that one missing arrow is the whole point.

Step 5 — Cut the wires entirely: the event broker

WHAT. Go back to the $n \times m$ mesh of Step 2. Instead of arranging arrows, we drop a broker in the middle. Every producer sends its event to the broker; every consumer subscribes to the broker. No producer knows any consumer.

WHY. Now each box connects only to one thing — the broker. Producers add $n$ wires in; consumers add $m$ wires out. The dreaded multiplication becomes an addition.

PICTURE. Compare directly to Step 2: the tangled $9$ -wire mesh becomes a clean hub with $3 + 3 = 6$ spokes. Add a new consumer and you draw exactly one new wire — the producers never notice.

Step 6 — Split the box across the network: microservices

WHAT. So far every box lived in one program. Now cut along business capabilities — Orders, Payments, Shipping — and give each its own database and its own deploy button. They talk only over the network (HTTP / events).

WHY. Three drivers: deploy one team's change alone, scale only the hot service, and match Conway's Law (architecture mirrors the org chart). The boundary is drawn around what a team owns, never around a technical layer.

PICTURE. Each service is a sealed box with a lock on its database — the red barred arrow shows another service is forbidden from reaching in. Compare the single shared cylinder of a monolith on the left to the three private cylinders on the right.

Step 7 — The edge case: what if the box is idle? (serverless)

WHAT. Take one microservice and ask: what happens when no request arrives? In Step 6 the box still runs, still costs money. Serverless removes the box: your code is a function the cloud runs only when an event fires, scaling from zero and billing per invocation.

WHY. This is the degenerate case of event-driven pushed into the infrastructure. Idle cost → $0$ . It is the natural end of the arrow-reduction story: no standing box means no standing wire.

PICTURE. The step plot shows cost. A reserved server is a flat orange line — you pay 24/7 even at night. The serverless blue line hugs zero when idle and spikes only under traffic. Where the two lines cross is the whole decision.

The one-picture summary

The whole chapter is one graph: how wire-count grows as the system grows. Read it left to right and you have re-derived every style.

The steep red curve is the naive mesh, $n \times m$ — the enemy.
Layered and MVC bend it down by forbidding arrows (direction rules).
The blue line is the broker, $n + m$ — the enemy tamed by a hub.
Microservices and serverless take that tamed graph and cut its boxes across the network / down to zero.

Recall Feynman retelling — say it back in plain words

We started with two boxes and one arrow, and called that arrow coupling — the thing that breaks when the other side changes. Then we let the system grow: $n$ callers each talking to $m$ answerers gives $n \times m$ arrows, a tangle that quadruples when you double the system. Layered architecture fought this not by deleting arrows but by forbidding them — only downward, never up, so a change on top can't ripple. MVC did the same trick inside the screen: three roles in a triangle, with the Model deliberately not allowed to reach the View, so one set of data can feed many screens. Event-driven attacked the tangle head-on: drop a broker in the middle, and $n \times m$ becomes $n + m$ because everyone talks only to the hub. Microservices took those boxes and split them across the network, each with its own locked database and its own deploy button — power that costs latency and disagreement. And serverless asked the last question: what about the idle box? It deletes the box entirely and charges you nothing when nothing runs. Every step was the same move: count the arrows, then decide which ones to forbid, reroute, split, or erase.

Recall

Direct mesh of $n$ producers and $m$ consumers costs how many wires? ::: $n \times m$ (multiply — each producer may need each consumer). An event broker changes that count to? ::: $n + m$ (add — each side touches only the broker). A closed layered stack of $L$ layers has how many dependency arrows? ::: $L - 1$ . In MVC, which arrow is deliberately absent, and why? ::: Model → View; so one Model can feed many Views. Serverless cost when invocations $N = 0$ ? ::: Approximately $0$ — both cost terms carry $N$ .