Midterm Practice Questions: How Modern Software Is Built in 2026

These practice questions cover the chapters highlighted at the top of Material for Midterm from How Modern Software Is Built in 2026: chapters 1.1–1.7, 2.1–2.7, 3.6, and 4.1–4.4. Use them to test yourself before the exam.

There are 59 questions here, grouped by difficulty — Easy, Medium and Hard, plus two Challenge questions at the end. Inside each difficulty level, the questions are grouped by chapter, in chapter order. Every question has a suggested answer in a box that starts collapsed. Try to answer each question yourself before you open its answer — that is what makes the practice work.

The practice questions on the material from this website are on separate pages: Midterm Practice Questions and Midterm Practice Questions: The Task App.

Practice Questions

Easy

Subject: 1.1 What a programming language is, and why there are so many

Question 1 · Multiple choice

A processor understands only machine code. A programming language is best described as:

  1. A finished program that runs without translation
  2. A human-readable notation for those instructions, with a precise grammar so a program can translate it without ambiguity
  3. A collection of ready-made code for one job, such as sending email
  4. The skeleton of a whole kind of application, which you fill in with your own parts

b. A programming language is the notation itself, written as source code. Option c describes a library; option d describes a framework; option a describes an executable after translation.

Subject: 1.2 Fit for purpose: what each language was designed to do

Question 2 · True or false

SQL is a general-purpose language, so a team could reasonably build a whole website — buttons, clicks, page layout, and all — using only SQL.

False. SQL is domain-specific: superb at describing questions about tables, but it has no way to draw a button, listen for a click, send an email, or lay out a page. It is used alongside a general-purpose language, never instead of one.

Subject: 1.3 Popularity, maturity, and community

Question 3 · Multiple choice

A business is choosing between two equally capable languages. Which of the following is NOT one of the site’s reasons that a popular, mature language is the better business choice?

  1. It is easier to hire developers who know it
  2. Problems have usually been hit before and solved in public
  3. It is guaranteed to be the fastest language for every job
  4. It is more likely to still be supported and patched in twenty years

c. Popularity helps hiring, answers, longevity, security, and tooling — but it says nothing about speed for every job. Speed is a separate factor (chapter 1.5), and the fastest language is often the wrong business choice.

Subject: 1.4 The ecosystem: packages and libraries

Question 4 · Fill in the blank

When a developer says “we added a ______,” they mean the project now relies on someone else’s package, fetched through a ______ such as pip for Python or npm for JavaScript.

dependency; package manager. A package manager fetches libraries from a central registry (PyPI for Python, npm for JavaScript) and keeps track of which versions the project uses.

Subject: 1.5 Speed and memory: when performance matters

Question 5 · True or false

Compiled languages such as C, C++, and Rust are typically ten to a hundred times faster than interpreted languages such as Python at raw computation, and use a fraction of the memory.

True. There is no interpreter in the way, and the programmer controls exactly how data is laid out. That is why compiled languages win where raw speed and memory are decisive — but most business applications wait on the database and network, not on computation.

Subject: 1.6 Platforms and portability

Question 6 · Matching

Match each way of reaching several platforms with its description.

Way | | Description |
— | | — |
1. Recompile for each platform | | A. Compile once to bytecode for an imaginary computer; a virtual machine on each real platform runs it |
2. Compile once, run on a virtual machine | | B. Ship the source itself; it runs anywhere the interpreter is installed |
3. Ship the source and interpret it | | C. Produce a separate program per platform, each needing its own compilation and testing |

1 → C, 2 → A, 3 → B. C and C++ recompile per platform; Java (JVM) and C# (.NET runtime) use the virtual-machine route; Python, JavaScript, and Ruby ship source to an interpreter.

Subject: 1.7 Making the decision in the age of AI

Question 7 · Multiple choice

According to the factor-weights table in chapter 1.7, which factor’s weight goes UP with AI assistance, and why?

  1. Fit for purpose, because AI can make any language run anywhere
  2. Popularity and maturity, because AI quality tracks how much public code exists
  3. Speed and memory, because AI makes every language equally fast
  4. Your own familiarity, because AI means you never need to review code

b. Popularity and maturity weigh higher: mainstream, stable languages get the best AI help, because assistants learn from the enormous body of public code and documentation. Fit for purpose is unchanged — AI cannot make SQL draw a button or make a browser run Python.

Subject: 2.1 Why architecture is a business topic

Question 8 · Fill in the blank

Architecture is the set of big structural decisions about software: what its major parts are, what each part is responsible for, and how the parts talk to each other. A business student should care because architecture decides ______, ______, and ______.

Cost, risk, and speed. Cost: whether you pay a few dollars a month or tens of thousands, and whether adding customers adds cost linearly or barely at all. Risk: what happens when a component fails or a breach occurs. Speed: how fast features can be added without breaking what works.

Subject: 2.2 Clients, servers, and programs

Question 9 · True or false

In the client–server model, the server speaks first and the client waits to be asked.

False. The client always speaks first. The server waits, answers, and forgets about the client until the next request arrives. That is why servers run 24 hours a day, waiting.

Subject: 2.3 A web page is three languages

Question 10 · Matching

Match each language with its job in a web page.

Language | | Job |
— | | — |
1. HTML | | A. What the page looks like: colors, fonts, spacing, layout |
2. CSS | | B. What the page does: reacting to clicks, checking a form, loading more posts |
3. JavaScript | | C. What is on the page: headings, paragraphs, images, links |

1 → C, 2 → A, 3 → B. HTML is content and structure (tags); CSS is appearance (rules); JavaScript is behaviour — the only language browsers can run.

Subject: 2.4 The static website on your own computer

Question 11 · Multiple choice

You save a text file as index.html on your laptop and double-click it. What happens, and what does the address bar show?

  1. Nothing — a browser cannot open a file without a server
  2. The browser displays it as a web page; the address starts with file:///
  3. The browser displays it, but only after you pay for hosting
  4. The browser displays it to anyone on the internet who knows your address

b. A static website needs no server at all on your own computer: the browser reads the files straight off your disk, and the address starts with file:///, meaning “a file on this machine,” not https://. Only you can see it that way.

Subject: 2.5 How the internet delivers a page

Question 12 · Multiple choice

In the URL https://shop.example.com/products/42?color=blue, which part picks the server, and which part passes extra details such as the colour?

  1. The server is picked by the path /products/42; extra details are in the domain
  2. The server is picked by the domain shop.example.com; extra details are in the query string ?color=blue
  3. The server is picked by the protocol https; extra details are in the path
  4. The server is picked by the query string; extra details are in the protocol

b. The domain picks the server; the path picks the file or page on it; the query string passes extra details, like a language or a search term.

Subject: 2.6 Front end, back end, and the limits of static sites

Question 13 · True or false

A purely static website can keep a shopping cart that survives a page reload, because the browser remembers it.

False. A static site cannot personalise: every visitor gets the same file, and nothing on the server knows who the visitor is, so there is no cart that survives a reload. That needs a back end — a program on the server that receives requests, runs logic, and reads and writes stored data.

Subject: 2.7 Where Python fits

Question 14 · Multiple choice

In a web application, where does Python code run?

  1. In the visitor’s browser, alongside JavaScript
  2. Only on the developer’s laptop, never on a server
  3. On servers, as back-end code — and on your own computer when you run a script
  4. Inside the database, instead of SQL

c. The browser can run only JavaScript; Python does not run in the browser. Python runs on servers as back-end logic, data processing, AI, scripts, and automation — that is why Python skills from the Python course are directly back-end skills.

Subject: 3.6 Putting it together: the three-tier architecture

Question 15 · Matching

Match each tier with its job.

Tier | | Job |
— | | — |
1. Presentation tier | | A. Receives requests, enforces business rules, talks to the database, returns responses |
2. Application tier | | B. Stores and retrieves the facts |
3. Data tier | | C. Shows things to people and collects their input, in the browser or a phone app |

1 → C, 2 → A, 3 → B. Presentation is the front end; application (logic / back end) is where business logic lives — prices, discounts, permissions, validation, workflows; data is the database.

Subject: 4.1 From localhost to production

Question 16 · Fill in the blank

Moving code that works on your own computer to a place where customers can reach it is called ______. Serious teams do not go straight from a laptop to customers: code passes through development, ______, and production environments.

deployment; staging. Development (“dev”, “local”) is each programmer’s own computer, with fake or sample data. Staging (“test”, “QA”) is a private replica of production to check a release before customers see it. Production (“prod”, “live”) serves real customers with real, protected, backed-up data.

Subject: 4.2 Step 1: everything on one server

Question 17 · Multiple choice

In the Step 1 single-server deployment, which program accepts connections on ports 80 and 443, handles HTTPS, serves static files itself, and forwards dynamic requests to the back end?

  1. The database (PostgreSQL)
  2. The back-end program (Python/Flask)
  3. The web server program (Nginx is the usual choice)
  4. The load balancer

c. Nginx accepts connections on ports 80 (HTTP) and 443 (HTTPS), serves the static files itself, and forwards dynamic requests to the back-end program, which listens on an internal port such as 5000. The database listens on its own internal port, 5432.

Subject: 4.3 Step 2: give the database its own machine

Question 18 · True or false

In the Step 2 design, the database server has a public internet address, so anyone can reach it directly.

False. The database server gets a private network address only — there is no route from the internet to it. A firewall allows connections on port 5432 only from the web server, so an attacker who compromises the web server still has another wall to get through.

Subject: 4.4 Step 3: many web servers behind a load balancer

Question 19 · Fill in the blank

______ scaling means replacing one machine with a bigger one. ______ scaling means running several identical copies of the web server. Modern web architecture is built around the second: in principle there is no ceiling.

Vertical (scaling up); horizontal (scaling out). Vertical scaling is simple with no code changes, but the biggest machine is still finite, price grows faster than capacity, and there is still exactly one of it. Horizontal scaling adds modest machines: twice the traffic, twice the servers.

Medium

Subject: 1.1 What a programming language is, and why there are so many

Question 20 · Short answer

A student says: “If AI can write correct syntax in any mainstream language, the choice of language no longer matters.” Use chapter 1.1 to explain why that conclusion is wrong, in two or three sentences.

Syntax is only the translation layer, and AI has largely absorbed it. The trade-offs of a language — what it was designed for, how fast it runs, where it can run, how mature its ecosystem is — are properties of the language itself, not of the person typing, and they do not disappear when an AI does the typing.

Subject: 1.2 Fit for purpose: what each language was designed to do

Question 21 · Scenario

A founder wants one language for everything: the browser pages, the server, and the database queries. Using chapter 1.2, explain why that plan fails in at least two places, naming the language that each place actually dictates.

The browser admits only JavaScript — no other language runs there, so the front end must be JavaScript. The database admits only its query language (SQL for a relational database) — SQL describes questions about tables, but cannot draw a button or run server logic. A modern product is never written in one language; “choosing a language” mainly means choosing the back-end language and the mobile strategy, because the rest is dictated by where the code has to run.

Subject: 1.3 Popularity, maturity, and community

Question 22 · Short answer

A team is tempted by a brand-new language that looks better designed than Python. Give the site’s cautious rule for this situation, and two risks of being an early adopter that the rule is protecting against.

The cautious rule: let others be early adopters unless the new language solves a problem you actually have. Risks: it has few libraries, it changes in ways that break existing code, and it has not yet shown it will survive — most successful languages needed ten years to become safe bets. A small pool of developers also makes hiring and long-term support harder.

Subject: 1.4 The ecosystem: packages and libraries

Question 23 · Scenario

An AI assistant suggests a package for charging credit cards that you have never heard of, and the install fails. According to chapter 1.4, what probably happened, and what must you check before any suggested dependency goes into a product?

The assistant probably hallucinated: it confidently named a package (or function) that does not exist, or that existed in an older version. The install failing or the code not running makes this easy to catch. Before a suggested dependency goes into a product, check that it is real, maintained, and reputable — because a dependency is part of your software supply chain, and a package you depend on may itself depend on fifty others, maintained by volunteers who may stop.

Subject: 1.5 Speed and memory: when performance matters

Question 24 · Scenario

A colleague says the new online store must be written in C++ “because it is the fastest language.” A web request for the store spends most of its time waiting for the database and the network. How do you respond, using chapter 1.5?

Speed of the language is the wrong measure here: most business applications wait, they do not compute. Whether the surrounding logic runs in one millisecond or ten is invisible next to a fifty-millisecond database query, and architecture (caching, more servers) buys far more speed than a faster language. Developer time also costs more than machine time — shipping in a week instead of a month is worth more than saving a few servers. Build in the productive language, measure, and rewrite only the specific slow part if measurement proves it necessary.

Subject: 1.6 Platforms and portability

Question 25 · Short answer

When Apple moved Macs from Intel chips to its own ARM chips in 2020, why did every compiled Mac program have to be rebuilt, and why did some software run slowly in an emulator for a year or two?

Machine code for one processor architecture is gibberish to another: Intel/AMD chips speak x86, while phones, Apple silicon Macs, and a growing share of servers speak ARM. A compiled program is tied to one kind of processor (and operating system), so each platform needs its own build and testing. Until a native ARM build existed, software had to run through an emulator, which is slower.

Subject: 1.7 Making the decision in the age of AI

Question 26 · Ordering

Put these three conclusions from chapter 1.7 in the order the chapter presents them, and state each in a phrase:

  • Optimise for readability, not typing speed
  • Choose mainstream
  • The language is rarely the risk
  1. Choose mainstream. Prefer the languages with the largest bodies of public code (Python, JavaScript/TypeScript, SQL, and Java or C# where the enterprise requires them, with Swift and Kotlin for native mobile) — that is where the assistant is most reliable and help is easiest to find.
  2. Optimise for readability, not typing speed. When AI writes most of the code, the human’s job becomes reading, reviewing, testing, and deciding; a language that is easy to read (Python was designed for exactly this) makes that job possible.
  3. The language is rarely the risk. Products fail far more often from unclear requirements, wrong data models, and missing security than from choosing Python over Go — so spend decision effort on architecture, pick a sensible mainstream language, and move on.

Subject: 2.1 Why architecture is a business topic

Question 27 · Scenario

Two bakery websites launch on the same day. One handles a viral spike and the other collapses; one costs a few dollars a month and the other tens of thousands. A student says both differences are “just luck.” How does chapter 2.1 answer that?

Neither difference is luck: both are consequences of architecture — the big structural decisions about what the major parts are, what each is responsible for, and how they talk to each other. Architecture decides cost (whether adding customers adds cost linearly or barely at all), risk (what happens when a component fails, and whether the product survives a viral moment), and speed (how fast features can be added without breaking what works). Like load-bearing walls, these decisions are enormously costly to change after they are poured.

Subject: 2.2 Clients, servers, and programs

Question 28 · Matching

Match each activity with its client and its server, as chapter 2.2 does.

Activity | | Client → Server |
— | | — |
1. Reading news on your phone | | A. Banking app → the bank’s servers holding account records |
2. Checking your bank balance | | B. Browser or news app on the phone → the newspaper’s computers holding the articles |
3. Asking Claude a question | | C. Claude app or Claude Code → Anthropic’s servers running the AI model |

1 → B, 2 → A, 3 → C. In every case the client asks and the server answers. Note also the two meanings of “server”: a server is an ordinary computer (usually with no screen or keyboard, in a data center, running 24 hours a day), and a web server is a program whose only job is to listen for requests and hand back web pages — several server programs can run on one physical computer.

Subject: 2.3 A web page is three languages

Question 29 · Short answer

A student writes: “JavaScript and Java are basically the same language, since JavaScript is just the web version of Java.” Correct the student, using chapter 2.3, and say where each language runs.

They are unrelated languages that share half a name for 1990s marketing reasons. JavaScript is the only language browsers can run, and it makes a page do things (react to clicks, check a form, load more posts); since 2009 it also runs on servers through Node.js. Java runs on servers and in Android apps. When people say “JS” they mean JavaScript.

Subject: 2.4 The static website on your own computer

Question 30 · Scenario

You change one word in the HTML file of your bakery site on your laptop, save, and refresh the browser — and the page changes. Your friend across town types what she thinks is your site’s address into her browser and sees nothing. Explain both observations.

The browser reads the files straight off your disk, so editing the file and refreshing shows the change immediately, with no server involved. But only you can see the page that way: your friend’s browser has no route to a file on your desktop. To share the site with the world, the files must be placed on a server that is always on and reachable by address.

Subject: 2.5 How the internet delivers a page

Question 31 · Ordering

Put these steps in the order they happen when a customer types https://www.rosenthalsbakery.com/menu.html and the page appears:

  • The browser opens a connection to the server and sends an HTTP request
  • The browser asks DNS for the server’s IP address
  • The browser sends further requests for style.css, app.js, and storefront.jpg
  • The server sends back an HTTP response, starting with a status code
  1. The browser asks DNS (“what is the IP address of www.rosenthalsbakery.com?”) — computers find each other by number, not by name, and DNS is the distributed phone book.
  2. The browser opens a connection to that server and sends an HTTP request (for example, GET /menu.html).
  3. The server sends back an HTTP response, whose first line carries a status code (200 OK for success).
  4. As the browser reads the HTML, it discovers it also needs the CSS, JavaScript, and images, and sends a separate request for each — a typical commercial home page makes 50 to 150 requests.

Subject: 2.6 Front end, back end, and the limits of static sites

Question 32 · Short answer

A bakery wants four features: a brochure page, a “Welcome back, Dana” greeting, a form whose submissions are stored, and a confirmation email after an order. Which of these can a purely static site do, and which need a back end? Explain in one sentence each.

Brochure page: static can do it — it is just files handed out unchanged to every visitor. Greeting, stored form, and confirmation email: all need a back end. A static site cannot personalise (nothing knows who Dana is), cannot remember anything (there is nowhere for form data to go), and cannot do work on your behalf (sending email requires a program running somewhere that is not the visitor’s browser). A website with a back end is dynamic: its pages are generated at the moment they are requested.

Subject: 2.7 Where Python fits

Question 33 · Matching

Match each technology with where it runs and its job in this module’s stack.

Technology | | Where it runs / job |
— | | — |
1. HTML, CSS | | A. Servers and your own computer — back-end logic, data processing, AI, scripts |
2. JavaScript | | B. Browser — content and appearance of pages |
3. Python | | C. Browser (also servers via Node.js) — interactivity; also a common back-end language |
4. SQL | | D. Database server — asking questions of stored data |

1 → B, 2 → C, 3 → A, 4 → D. A developer who works on the front end is a front-end developer, on the back end a back-end developer, and on both a full-stack developer; “the stack” is the list of technologies a product uses, top to bottom.

Subject: 3.6 Putting it together: the three-tier architecture

Question 34 · Scenario

Dana clicks “Order 2 challahs” on the bakery site. Trace the order through the three tiers, and say at which tier the 10%-off-over-$50 discount rule is enforced — and why it must be there, not in the browser.

Presentation tier (browser): shows the page and collects Dana’s click and input. Application tier (server program): receives the request, enforces business rules — including the discount — talks to the database, and returns a response. Data tier (database): stores and retrieves the order facts. The discount rule lives in the application tier, on the server, because the browser can never be trusted with secrets or with enforcing rules: anything in the browser can be changed by the person using it, and the browser never talks to the database directly — all access goes through the back end, which checks identity and applies rules.

Subject: 4.1 From localhost to production

Question 35 · Multiple choice

A team says: “It works on my machine, so let’s push it straight to customers — staging is a waste of time.” Which response best follows chapter 4.1?

  1. Agree — staging and production use identical data, so staging catches nothing
  2. Refuse staging only for small sites, since only large sites have bugs
  3. Keep staging, because development and production differ (operating system, database size, traffic, secrets), and staging catches those differences before a customer does
  4. Skip staging but add more “nines” of uptime instead

c. “It works on my machine” is the oldest joke in software precisely because development and production differ. Staging is a private replica of production, with realistic but not real (or anonymised) data, to check a release before customers see it. The honest answer to “can we just push it live?” is: only if you would be comfortable finding the bugs at the same moment your customers do.

Subject: 4.2 Step 1: everything on one server

Question 36 · Short answer

Name the four things installed on the Step 1 single server, and explain why a heavy report query can make the website slow for every visitor in this setup.

Operating system (almost always Linux on servers); the web server program (Nginx, on ports 80 and 443); the back-end program (Python/Flask, on an internal port such as 5000); the database (PostgreSQL, on its own internal port, 5432). A heavy report query slows everyone because of resource contention: the database and the back end compete for the same memory and processor on the same machine, and every component shares the same fate.

Subject: 4.3 Step 2: give the database its own machine

Question 37 · Scenario

A startup moves its database to its own machine, then asks: “We now pay two bills instead of one — what did we actually buy?” Give three answers from chapter 4.3.

  1. Right-sized hardware: databases want lots of memory and fast disks, web servers want processor cores and network bandwidth — separated, each can be bought for what it actually needs. (2) Security: the database sits on a private network, reachable on port 5432 only from the web server, so an attacker who compromises the web server still faces another wall. (3) Independent failure and maintenance: the web server can be rebuilt or upgraded without touching a byte of data, backups run without slowing the website — and, crucially, with the data in one shared place, you can now run more than one copy of the web server (Step 3).

Subject: 4.4 Step 3: many web servers behind a load balancer

Question 38 · Short answer

A customer logs in on web server 1, clicks again, is routed to web server 2, and is asked to log in again. The site looks broken. What is the cause, what is the required fix, and where does the remembered information go instead?

Cause: web server 1 remembered the login, but web server 2 never heard of the customer — the servers were not stateless. Fix: web servers must be stateless, remembering nothing between requests. Everything that needs remembering (who is logged in, what is in the shopping cart) is stored somewhere all servers can reach — the database, or a fast shared store such as Redis — and the information travels with the request (in a cookie). Any server can then handle any request, which is what makes servers interchangeable and scaling possible.

Hard

Subject: 1.1 What a programming language is, and why there are so many

Question 39 · Compare

Compare a compiler and an interpreter on two axes: speed of the resulting program, and portability of the program. Use the site’s book-translation analogy for at least one axis, and name two languages for each strategy.

Speed: a compiled program runs very fast, because the whole program is translated ahead of time into an executable; an interpreted program is slower, because the interpreter carries it out line by line on the spot. Portability: a compiled file is tied to one kind of processor and operating system (a separate edition for every language, in the book analogy — readers get it fast, but you need a separate edition each time), while the same interpreted source runs wherever the interpreter is installed (a live interpreter at a meeting: slower, but the same speech works in any room where an interpreter is present). Compiled: C, C++, Rust, Go, Swift. Interpreted: Python, JavaScript, Ruby. Java and C# sit in between (chapter 1.6).

Subject: 1.2 Fit for purpose: what each language was designed to do

Question 40 · Scenario

A product needs: (a) a rich interactive web front end, (b) AI and data-analysis features, (c) a native iPhone app, and (d) reports over a relational database. A founder proposes writing it all in Python. Using chapter 1.2’s home-turf table, accept or correct each part, and state the general lesson.

  1. Correct only in part: the front end cannot be Python — the browser runs only JavaScript, so the rich front end must be JavaScript/TypeScript (React, Vue, and all browser tooling live there). (b) Accept: Python is the language of the AI industry, and every major AI library is Python-first. (c) Correct: a native iPhone app is Swift, Apple’s preferred language and the best experience on its devices — Python is not the native choice. (d) Accept with a correction: reports use SQL, but SQL is domain-specific and is used alongside a general-purpose language, never instead of one. Lesson: a modern product is never written in one language; each layer is dictated by where the code has to run.

Subject: 1.3 Popularity, maturity, and community

Question 41 · Long answer

Chapter 1.3 says popularity matters more than before in the age of AI, for a new reason — even though one old reason has weakened. Explain both halves: which old reason weakened and why, and what the new reason is, with an example of a language that gets outstanding AI support versus one that gets weaker help.

The hiring argument has weakened a little: AI can cover a skills gap, so a team is less dependent on already knowing a language. But the “quality of AI help” argument has more than replaced it: AI assistants learn from the enormous body of public code and documentation on the internet, so the more a language has been written and discussed, the better the assistant is at writing it. Python, JavaScript, TypeScript, Java, and SQL get outstanding support; a niche or very new language gets noticeably weaker, more error-prone help. The same applies to versions: an assistant trained mostly on last year’s version of a fast-changing framework will confidently produce last year’s code. If you build with AI, build in the languages the AI knows best, on stable, well-documented versions.

Subject: 1.4 The ecosystem: packages and libraries

Question 42 · Compare

Compare the ecosystem pull for two products: (a) a product mostly about AI, machine learning, and data analysis, and (b) a native iPhone app. For each, name the language the ecosystem pulls you toward and why, and state what “open source is a software supply chain” means for both.

  1. Python: every major AI library (PyTorch, scikit-learn, pandas, the Claude and OpenAI SDKs) is Python-first; other languages get ports later, if at all. (b) Swift: Apple builds its libraries and tools for Swift first, and it is Apple’s preferred language. “Open source is a software supply chain” means both products build on freely published packages that anyone can use, inspect, and improve — which is why a two-person startup can build on the same foundations as a bank — but a package you depend on may itself depend on fifty others, each maintained by volunteers who may stop, and occasionally one is abandoned or deliberately sabotaged. Mature ecosystems have tooling that flags known-vulnerable packages.

Subject: 1.5 Speed and memory: when performance matters

Question 43 · Scenario

Three products are proposed: (1) a sensor device with 256 kilobytes of memory and a battery to preserve, (2) a video-processing tool that must produce 60 frames a second, and (3) an online store whose requests spend most of their time waiting for the database. For each, say whether language speed decides the choice, and name a typical choice (or approach) from chapter 1.5.

  1. Yes, decisively: kilobytes of memory, a slow processor, and a battery mean every byte and cycle counts — C, C++, or Rust. (2) Yes, decisively: 60 frames a second leaves 16 milliseconds per frame for everything — C++, C# (Unity), or Rust. (3) No: most business applications wait, they do not compute, so a 1-millisecond versus 10-millisecond logic difference is invisible next to a 50-millisecond database query. Build in the productive language (Python and the like serve enormous audiences this way), use architecture — caching, more servers — for speed, measure, and rewrite only the specific slow part if measurement proves it necessary. Note also that the slow language often calls the fast one: Python’s data and AI libraries are Python outside and C/C++ inside.

Subject: 1.6 Platforms and portability

Question 44 · Compare

A company wants the best possible app on both iPhone and Android, and also wants one codebase for Windows, Mac, and Linux desktops. Compare the two strategies chapter 1.6 offers for each goal, including what each costs.

Mobile: native means writing the app twice — Swift (and its predecessor Objective-C) for iOS, Kotlin (and older Java) for Android — because each platform built its preferred language, libraries, design conventions, and store tooling first; the cost is duplicated work, in exchange for the best user experience. The alternative is a cross-platform framework such as React Native (JavaScript) or Flutter (Dart): one codebase produces both apps, at some cost in performance and in fidelity to each platform’s conventions. Desktop: Electron plays the same role, wrapping a web app so Slack, VS Code, and Discord ship one codebase to Windows, Mac, and Linux. The business reading: every additional platform is an additional product to build, test, and support; the web minimises that duplication, virtual-machine languages nearly eliminate it for desktop/server software, and compiled languages maximise it but run fastest.

Subject: 1.7 Making the decision in the age of AI

Question 45 · Long answer

Using the full factor-weights table in chapter 1.7, state for each of the five factors — fit for purpose, popularity and maturity, ecosystem, speed and memory, platforms, plus your own familiarity — whether its weight is unchanged, higher, or lower with AI assistance, and give the reason in a phrase each.

Fit for purpose: unchanged — platforms dictate the browser, database, and mobile languages; AI cannot override that. Popularity and maturity: higher — AI quality tracks how much public code exists, so mainstream, stable languages get the best help (the hiring part of this factor weakened, but this more than replaces it). Ecosystem: unchanged to higher — AI uses libraries rather than replacing them, and rich ecosystems are even more valuable, but verify that suggested packages are real. Speed and memory: same domains decisive, elsewhere lower — rewriting a hot spot in a fast language is now cheap, so start productive and optimise after measuring. Platforms: lower for writing, unchanged for testing — AI ports code, but people still must verify every platform. Your own familiarity: lower but not zero — AI lets you build in a language you do not know, but you still have to review what it wrote and understand it when it breaks.

Subject: 2.1 Why architecture is a business topic

Question 46 · Scenario

A founder says: “Architecture is an engineering topic. I will hire engineers for that and focus on the business.” Using chapter 2.1 and the module’s opening argument, explain why a business student who cannot follow the architecture conversation “does not get a vote” — with one cost example, one risk example, and one speed example.

Architecture decisions are business decisions in disguise. Cost: architecture decides whether you pay a few dollars a month or tens of thousands, and whether adding customers adds cost linearly or barely at all. Risk: it decides what happens when a server fails at 2 a.m., how a data breach could occur, and whether the product survives a viral moment or collapses under it. Speed: it decides how fast a team (or you with an AI coding assistant) can add features without breaking what already works — and whether a customer’s password is protected. You will not write the load-bearing walls yourself, but you will approve them or be asked to, and the person who cannot follow the conversation does not get a vote.

Subject: 2.2 Clients, servers, and programs

Question 47 · Short answer

A student says: “A server must be a special, powerful kind of computer, different from a laptop.” Correct the student on both meanings of the word “server,” and explain where servers usually live and why they have no screen or keyboard.

A server is an ordinary computer: it has a processor, memory, and a disk exactly like a laptop. It usually has no screen or keyboard because nobody sits at it; it lives in a building full of other servers (a data center) with reliable power, cooling, and a fast internet connection, and runs 24 hours a day, waiting. “Server” also names a program: a web server is a program whose only job is to listen for requests and hand back web pages, and the same physical computer can run several server programs at once. In conversation, “the server” means whichever of the two is obvious from context.

Subject: 2.3 A web page is three languages

Question 48 · Scenario

A page shows black text on white, in default fonts, with no layout, but its headings, paragraphs, image, and link are all present and correct. A second page looks beautiful but does nothing when its button is clicked. Diagnose each page in terms of the three languages, and say what the browser’s act of turning the text files into pixels is called.

First page: HTML alone, without CSS — HTML gives a working but ugly page (black text on white, default fonts, no layout), because CSS is what says how the page looks. Second page: HTML and CSS without working JavaScript — without JavaScript a page is a document; with it, a page becomes an application that reacts to clicks, checks a form, or loads more posts. The browser’s act of turning the three plain-text files into pixels is called rendering, and every browser does it slightly differently, which is why the same site can look marginally different in Safari and Chrome.

Subject: 2.4 The static website on your own computer

Question 49 · Long answer

Chapter 2.4 calls a static website on your own computer “the zero-cost, zero-infrastructure starting point from which everything else in this module is built up.” Explain that claim: what does it cost, what infrastructure does it need, what does it prove about the three languages, and what is its one decisive limitation?

Cost and infrastructure: zero — a text file named index.html, double-clicked, is displayed by the browser with no internet connection, no server, and no company involved. What it proves: a web page is a plain text file, written in up to three languages (HTML for structure, CSS for appearance, JavaScript for behaviour), and the browser combines them into the page. Limitation: only you can see it. Your friend across town cannot type anything into a browser that reaches a file on your desktop — to share it, the files must be placed on a server that is always on and reachable by address, which is the subject of chapter 2.5.

Subject: 2.5 How the internet delivers a page

Question 50 · Scenario

Three customers report three different errors: one sees 404 Not Found, one sees 500 Internal Server Error, and one sees 503 Service Unavailable. For each, say what happened, who (if anyone) did something wrong, and what the business should do first.

404 Not Found: no such page — a typo in the address or a deleted page. The visitor (or a bad link) is the likely cause; fix the link or restore/redirect the page. 500 Internal Server Error: the server’s own code crashed — a bug in the site; the visitor did nothing wrong. The business must fix its code. 503 Service Unavailable: the server is overloaded or down for maintenance — for example ticket sales opening or launch-day traffic. The business needs capacity or maintenance handling, not a code fix for a visitor error. For contrast: 200 OK is success; 301 Moved Permanently means “that moved, go here instead” (old links that still work after a redesign); 401 Unauthorized / 403 Forbidden mean “you need to log in / you are not allowed.”

Subject: 2.6 Front end, back end, and the limits of static sites

Question 51 · Long answer

Chapter 2.6 says a static site “cannot keep secrets” — and calls this one of the most important security rules in the module. Explain why, using the fact that everything in a static site is sent to the visitor’s browser, and give two things that must therefore never live in front-end code.

Everything in a static site is sent to the visitor’s browser, so anything in it can be read by anyone. A password, a payment key, or a private price list therefore cannot live in front-end code — anyone who receives the page receives the secret. Secrets and rule-enforcement must live in the back end, on the server, out of sight: the code that decides what to send, checks who you are, records an order, and charges a card. Most real products mix the two: marketing pages are static, while the product behind the login button is dynamic — and knowing which parts genuinely need a back end is one of the first cost-saving architecture decisions a founder can make.

Subject: 2.7 Where Python fits

Question 52 · Scenario

A student in the Python course asks: “If I am learning Python, can I write the part of a website that visitors see and click on?” Answer the student, explain the stack that this module uses instead, and say what a full-stack developer is.

No — not in Python. The browser can run only JavaScript, so the part visitors see and click on (the front end) must be HTML, CSS, and JavaScript. Python runs on servers as back-end code, and on your own computer when you run a script. This module’s stack is HTML, CSS, and JavaScript in the browser, Python on the server, and SQL in the database (with Swift and Kotlin named for native phone apps). A developer who works on the front end is a front-end developer, on the back end a back-end developer, and on both a full-stack developer; “the stack” is the list of technologies a product uses, top to bottom.

Subject: 3.6 Putting it together: the three-tier architecture

Question 53 · Scenario

A developer proposes: “To make the bakery site faster, let the browser query the database directly, skipping the back end for read-only product lists.” Using chapter 3.6, explain why this is rejected even for reads, and name the two independence benefits that the three-tier arrangement gives instead.

Rejected because the browser never talks to the database directly: all access goes through the back end, which checks identity and applies rules. If a browser could send SQL, anyone could run DELETE FROM orders — and the front end can never be trusted with secrets or with enforcing rules, since anything in the browser can be changed by the person using it. The three-tier arrangement instead gives: (1) each tier can be changed independently — redesign the front end without touching the database, swap SQLite for PostgreSQL without changing the HTML, rewrite the back end from Python to something else while the other tiers carry on; (2) each tier can be placed on different hardware — today all three on one laptop, tomorrow the database on its own machine and the back end copied onto ten (Session 4).

Subject: 4.1 From localhost to production

Question 54 · Scenario

A hobby site runs at 99% uptime, a small business product at 99.9%, and a payment system at 99.99%. For each, state the downtime allowed per year from chapter 4.1, and explain why the payment system cannot simply “add one more nine” for free.

99% allows about 3.7 days of downtime per year (a hobby site on one cheap server). 99.9% (“three nines”) allows about 8.8 hours (a small business product with sensible hosting). 99.99% (“four nines”) allows about 53 minutes (payment, banking, large SaaS). Each extra “nine” is dramatically more expensive to achieve, because four nines requires redundancy at every layer — and five nines (about 5 minutes, telecom and critical infrastructure) is very expensive. Uptime is the percentage of time a system is reachable; latency is how long each request takes to answer; much of Session 4’s architecture exists to push uptime up and latency down.

Subject: 4.2 Step 1: everything on one server

Question 55 · Long answer

A modest $20 server can handle tens of thousands of visits a day, yet chapter 4.2 lists four weaknesses that appear with growth. Name all four, and for each give the concrete failure or cost it describes.

  1. Single point of failure: if the machine’s disk dies, the data center loses power, or you make a mistake while updating it, the website and the database disappear together — a single point of failure is the enemy of uptime. (2) Resource contention: the database and the back end compete for the same memory and processor, so a heavy report query can make the website slow for every visitor. (3) Hard ceiling: when traffic outgrows the machine, the only option is a bigger machine, and machines do not get infinitely big. (4) Security blast radius: if an attacker breaks into the web server, they are already sitting on the same machine as all the customer data. Each following step in Session 4 removes one weakness and adds cost and complexity — take the next step when the problem is real, not before.

Subject: 4.3 Step 2: give the database its own machine

Question 56 · Compare

Compare running your own PostgreSQL on a rented machine with using a managed database (such as Amazon RDS, Google Cloud SQL, Supabase, or Neon). What does the managed service take over, what do you get instead of a server to operate, and what is chapter 4.3’s recommendation for nearly every business?

A managed database takes over running the machine, nightly backups, security patches, and automatic failover — switching to a standby copy automatically if the primary fails. You get a connection address and a bill, instead of a server to operate. Chapter 4.3’s recommendation: for nearly every business, the managed database is the correct choice; running your own database is expertise you do not want to have to hire. This does not remove the Step 2 design itself: the database still sits on a private network, reachable on port 5432 only from the web server, and still lets each machine be sized for its own job.

Subject: 4.4 Step 3: many web servers behind a load balancer

Question 57 · Long answer

The bakery is featured on a national morning show and ten thousand people open the site in the same minute. Explain, using chapter 4.4, (a) why the single web server answers with 503 errors, (b) how a load balancer fixes the routing problem that several servers create, (c) what health checks do, and (d) why this whole step fails unless the servers are stateless.

  1. The single web server, already the busiest machine, runs out of capacity — 503 Service Unavailable means the server is overloaded or down for maintenance. Vertical scaling (a bigger machine) is finite and price grows faster than capacity; horizontal scaling (several identical copies) has in principle no ceiling. (b) The domain resolves to one IP address, so a load balancer sits in front of all the servers, owns the public address, accepts every request, and forwards each to one server behind it, spreading work evenly (round-robin, or to whichever is least busy). (c) Health checks: every few seconds the load balancer pings each server, and if one stops answering it simply stops sending it traffic — customers never notice. (d) Statelessness is required because otherwise a customer logged in on server 1 would be unknown to server 2 on their next click. Stateless servers remember nothing between requests; what must be remembered lives in the shared database or session store (such as Redis), and the information travels with the request. With two or more servers, one can fail, be updated, or be replaced while the others carry on — redundancy at every layer is high availability, and it is how three and four nines of uptime are bought.

Challenge

Question 58 · Long answer

A founder is launching a small online bakery. Walk through the architecture decisions from this material, in order: (1) which languages, and why, for the browser, the server, and the database; (2) whether the marketing pages and the ordering system should both be dynamic, and why not; (3) which tier enforces the discount rule and why; (4) which deployment step (Step 1, 2, or 3) is sensible at launch, and what problem would justify moving to the next step. Justify each choice from chapters 1.2, 2.6, 3.6, and 4.2–4.4.

  1. Browser: HTML, CSS, and JavaScript — the browser runs only JavaScript, and HTML/CSS describe structure and appearance. Server: Python (this module’s stack, and the language of the AI industry, with the deepest AI support) — the back-end choice is the one most worth thinking about, because the server admits almost any language. Database: SQL over a relational database — SQL is domain-specific for asking questions of tables, used alongside a general-purpose language. (2) No: marketing pages can stay static — they are cheap, fast, hard to hack, and almost impossible to overload — while only the ordering system behind the login needs a back end. A static site cannot remember, personalise, keep secrets, or do work such as sending a confirmation email or charging a card. (3) The application tier, on the server: business logic (prices, discounts, permissions) lives there, because the browser can never be trusted to enforce rules and never talks to the database directly. (4) Step 1 at launch: one VPS with Linux, Nginx, the Python back end, and PostgreSQL — a modest server handles tens of thousands of visits a day, covering most small businesses and every early prototype. Move to Step 2 (database on its own machine, private network) when contention, security, or maintenance of shared hardware becomes real; move to Step 3 (many web servers behind a load balancer, stateless servers) when a traffic spike would otherwise produce 503 errors — taking each step when the problem is real, not before.

Question 59 · Scenario

A team proposes three shortcuts, and asks you to approve all three: (a) “Let the browser hold the payment key, so checkout is faster”; (b) “Skip staging — our code works on our laptops”; (c) “Store each user’s login state in memory on whichever web server handled their first request, to avoid a shared store.” Reject each shortcut, naming the chapter and principle it breaks, and state what to do instead in each case.

  1. Reject — chapters 2.6 and 3.6: a static/front-end site cannot keep secrets, because everything sent to the browser can be read by anyone, and the browser never talks to trusted systems directly. Instead, keep the payment key in the application tier, on the server, and let the back end charge the card. (b) Reject — chapter 4.1: development and production differ (operating system, database size, traffic, secrets), and staging is the private replica that catches those differences before customers do. Instead, pass code through development, then staging (realistic but not real data), then production. (c) Reject — chapter 4.4: web servers behind a load balancer must be stateless, or a customer routed to a different server will appear logged out. Instead, store login and cart state in the shared database or a fast shared store such as Redis, with the information travelling with the request, so any server can handle any request and servers stay interchangeable.

© 2025-2026 Y. Rosenthal. All rights reserved.