Chapter 19: Building the Skyscraper (Architecture)

Learning Objectives

• Understand why 100,000 lines of unstructured code is impossible to maintain.
• Learn the principle of Separation of Concerns.
• Understand the MVC (Model-View-Controller) architecture.
• Learn common Design Patterns (Observer, Singleton).

Prerequisites

Chapter 9: Object-Oriented Programming.

Why Does This Exist?

Building a doghouse requires some wood and nails. Building a 100-story skyscraper requires blueprints, steel framing, zoning laws, and a deep understanding of structural integrity.

If you put your Database SQL queries, your HTML UI code, and your Business Logic (tax calculations) all inside one massive 5,000-line function, it is "Spaghetti Code".

If the marketing team wants to change a button from Blue to Red, the engineer might accidentally break the tax calculation while scrolling through the file.

We needed Architecture: strict rules on where code lives and how it is allowed to talk to other code.

History

In 1994, four authors (known as the "Gang of Four") wrote a famous book cataloging 23 classic "Design Patterns". These were standardized templates for solving common software problems.

Simultaneously, architectural patterns like MVC (invented in the 1970s for Smalltalk) became the absolute gold standard for web development frameworks (like Ruby on Rails and Django).

Mental Model

Think of a Restaurant.

The View (The Dining Room): Where the UI lives. It looks pretty. The View knows NOTHING about how to cook food.

The Model (The Kitchen/Pantry): Where the raw data (ingredients) and Database live. The Kitchen knows NOTHING about the color of the tablecloths.

The Controller (The Waiter): The middleman. The Waiter takes an order from the View, walks to the Kitchen, gets the data, and hands it back to the View.

By keeping these strictly separate, you can burn down the dining room and build a new one (a Mobile App instead of a Website), and the Kitchen (the Database) doesn't have to change a single line of code.

Internal Working

This is achieved through Separation of Concerns and Dependency Injection.

Instead of a class hardcoding a connection to a specific PostgreSQL database, you pass the database into the class as a generic variable. Now, the class doesn't care if the database is Postgres, MySQL, or a fake mocked database for testing (Chapter 18). It just calls db.save().

Syntax

Architecture is not a syntax; it is a structural concept. Here is MVC in pseudo-Python:

1# MODEL (Data & Logic)
2class User:
3    def save_to_db(self):
4        # SQL execution here
5
6# VIEW (UI)
7def render_profile(user_data):
8    return f"<h1>{user_data.name}</h1>"
9
10# CONTROLLER (The brain connecting them)
11def profile_route(request_id):
12    user = User.get_by_id(request_id) # Talk to Model
13    html = render_profile(user)       # Talk to View
14    return html

Visual Explanation

Tiny Example

The Observer Pattern. (How a button click magically triggers a function).

1class Button:
2    def __init__(self):
3        self.listeners = []  # Array of functions
4
5    def add_listener(self, func):
6        self.listeners.append(func)
7
8    def click(self):
9        for func in self.listeners:
10            func()  # Broadcast the event!

Common Mistakes

Debugging

In highly abstracted code, tracing a bug is hard because functions are scattered across 20 folders.

You must master your IDE (like VS Code or IntelliJ). Use "Go to Definition" (Cmd/Ctrl + Click on a function name) to instantly jump through the layers of the architecture.

Mini Project

Time: 20 minutes.

Goal: The Singleton Pattern.

A Singleton ensures that a Class can only ever be instantiated ONCE. (Useful for a single Database Connection manager). Create a class with a private class-level variable _instance. Write a get_instance() method. If _instance is None, create it. If it already exists, return the existing one. Prove that calling it twice returns the exact same memory address.

# MVC pattern — separating concerns
# Model: data and business logic
# View: presentation
# Controller: orchestration

# ── MODEL ──
class UserModel:
    def __init__(self):
        self._users = {}
        self._next_id = 1

    def create(self, name, email):
        if any(u["email"] == email for u in self._users.values()):
            raise ValueError(f"Email already exists: {email}")
        uid = self._next_id
        self._users[uid] = {"id": uid, "name": name, "email": email, "active": True}
        self._next_id += 1
        return self._users[uid]

    def find_by_id(self, uid):
        return self._users.get(uid)

    def all(self):
        return list(self._users.values())

    def deactivate(self, uid):
        if uid not in self._users:
            raise KeyError(f"User {uid} not found")
        self._users[uid]["active"] = False

# ── VIEW ──
class UserView:
    @staticmethod
    def show_user(user):
        status = "✅" if user["active"] else "❌"
        print(f"  {status} #{user['id']:3} {user['name']:20} {user['email']}")

    @staticmethod
    def show_list(users):
        print(f"  {'St':4} {'ID':4} {'Name':20} {'Email'}")
        print("  " + "─" * 60)
        for u in users:
            UserView.show_user(u)

    @staticmethod
    def show_error(msg):
        print(f"  ⚠️  Error: {msg}")

# ── CONTROLLER ──
class UserController:
    def __init__(self):
        self.model = UserModel()
        self.view = UserView()

    def register(self, name, email):
        try:
            user = self.model.create(name, email)
            print(f"  ✅ Registered user #{user['id']}: {user['name']}")
        except ValueError as e:
            self.view.show_error(str(e))

    def list_users(self):
        users = self.model.all()
        print(f"
=== Users ({len(users)}) ===")
        self.view.show_list(users)

    def deactivate(self, uid):
        try:
            self.model.deactivate(uid)
            print(f"  Deactivated user #{uid}")
        except KeyError as e:
            self.view.show_error(str(e))

# ── MAIN ──
ctrl = UserController()
ctrl.register("Tarun Sharma",  "tarun@x.com")
ctrl.register("Alice Johnson", "alice@x.com")
ctrl.register("Bob Williams",  "bob@x.com")
ctrl.register("Alice Johnson", "alice@x.com")  # Duplicate email
ctrl.list_users()
ctrl.deactivate(2)
ctrl.list_users()

Bigger Project

Time: 1.5 hours.

Goal: Refactor Spaghetti to MVC.

Write a single massive Python script that does three things: Connects to SQLite and reads a table of users, loops through them to generate a giant HTML string, and saves it to a file. Now, create three separate files: models.py, views.py, and controller.py. Move the SQL into models, the HTML string logic into views, and use the controller to tie them together.

# Observer (Pub/Sub) design pattern — decoupled event system
from typing import Callable, Dict, List
import time

# ── EVENT BUS ──
class EventBus:
    """
    The core of event-driven architecture.
    Publishers emit events. Subscribers listen. They never know about each other.
    """
    def __init__(self):
        self._subscribers: Dict[str, List[Callable]] = {}

    def subscribe(self, event_type: str, handler: Callable):
        if event_type not in self._subscribers:
            self._subscribers[event_type] = []
        self._subscribers[event_type].append(handler)
        print(f"  📡 Subscribed to '{event_type}': {handler.__name__}")

    def publish(self, event_type: str, payload: dict):
        handlers = self._subscribers.get(event_type, [])
        print(f"
  🔔 Event: '{event_type}' → {len(handlers)} subscriber(s)")
        for handler in handlers:
            handler(payload)

# ── SERVICES (subscribers — they don't know about each other) ──
def send_welcome_email(payload):
    print(f"    📧 [EmailService] Sending welcome email to {payload['email']}")

def create_audit_log(payload):
    timestamp = time.strftime("%Y-%m-%d %H:%M:%S")
    print(f"    📋 [AuditService] LOG [{timestamp}] User registered: {payload['name']}")

def sync_to_analytics(payload):
    print(f"    📊 [Analytics] New user event: user_id={payload['id']}, source={payload.get('source','organic')}")

def notify_admin(payload):
    print(f"    🔔 [AdminPanel] New user #{payload['id']} — review required if premium")

# ── WIRING ──
bus = EventBus()
bus.subscribe("user.registered", send_welcome_email)
bus.subscribe("user.registered", create_audit_log)
bus.subscribe("user.registered", sync_to_analytics)
bus.subscribe("user.registered", notify_admin)
bus.subscribe("user.deleted",    create_audit_log)

# ── SIMULATION ──
print("
=== Event-Driven Architecture Demo ===")

# When a user registers, we publish ONE event.
# All four services react automatically — zero coupling between them.
bus.publish("user.registered", {
    "id": 42, "name": "Tarun Sharma", "email": "tarun@x.com", "source": "referral"
})

bus.publish("user.deleted", {
    "id": 17, "name": "Old Account", "email": "old@x.com"
})

print("
Key insight: The registration code doesn't import EmailService,")
print("AuditService, or Analytics. They are completely decoupled.")

Production Usage

Beyond MVC, massive companies like Netflix use Microservices Architecture.

Instead of one massive backend codebase, they have 1,000 tiny, independent mini-servers. The "Billing Service" is a tiny server that only handles money. The "Video Service" only streams video. They communicate over APIs (Chapter 16). If the Billing team breaks their code and their server crashes, Netflix users can still stream video.

Best Practices

• DRY (Don't Repeat Yourself): If you copy-paste the exact same 10 lines of code in 4 different places, you have failed. Move those 10 lines into a reusable helper function.
• Single Responsibility Principle: A class or function should do exactly ONE thing. If a function is called calculate_tax_and_send_email(), split it into two functions.

Interview Questions

Revision Sheet

Connections

• Previous Chapter: Good architecture (Dependency Injection) is the only way to write good Automated Tests (Chapter 18).
• Future Chapters: Our code is perfect, tested, and beautifully architected. Now, how do we get it out of our laptop and onto the internet? Deployment (Chapter 20).