2 — Backend Engineering Across Frameworks

Backend Engineering: Companion Note The mental model: one request, one worker, one connection COMPANION NOTE Backend Engineering: FastAPI, Django, Flask, Spring Boot, .NET and Node What the slides cannot hold: numbers, tradeoffs, decision rules and failure modes Md Ahbab Hamid Khan https://ahbab.dev/ ORIENTATION 1 How to use this note • The deck gives the definitions. This note gives the numbers, the tradeoffs and the decision rules. • Each table answers a question a bullet list cannot: what does this choice cost you later. • Each figure shows a shape, not a benchmark. Read the trend, ignore the absolute values. • Failure modes are written as symptom, likely cause, first check, so they are usable on a bad day. • Sizing formulas for workers, pools and connections let you plan a service before it is live. • The self check at the end shows whether you can use the vocabulary or only recognise it. FOUNDATIONS 2 The mental model: one request, one worker, one connection Hold three objects in your head. A request is one unit of work with a deadline. A worker is the thing that runs it: an operating system process, a thread, or a coroutine on an event loop. A connection is a scarce resource the r

Backend Engineering: Companion Note Reading the comparison spine Rule of thumb. If you cannot say how many requests are in flight, how many workers exist, and how many database connections they share, you cannot reason about your own service. Write those three numbers down before you tune anything. Production server Gunicorn, Kestrel, Tomcat, node Router match path, method, params Validation at the edge typed schema Dependency layer auth, config, clients Data access session and transaction Serialize and respond response leaves on the same worker that accepted it A blocking call placed anywhere in this band, a sync driver, a CPU heavy loop, a file read, holds the worker or the whole event loop and stalls every other request Figure 1. The life of one HTTP request. The amber box marks the edge, the only place raw input should be accepted. The panel below marks where a blocking call does the most damage. COMPARISON 3 Reading the comparison spine The deck compares six frameworks against one fixed list of items. The list is not a feature checklist. Each item tests a property of the framework that shows up much later, usually as maintenance cost. Table 1 places the six frameworks side by si

Backend Engineering: Companion Note Concurrency without hand waving building into controllers. A year later you cannot change the schema without touching the HTTP layer. Migrations. Tests whether schema change is a versioned artefact reviewed like code. A weak answer is hand written SQL applied by whoever remembers. A year later staging and production have quietly different schemas. Auth. Tests whether identity, sessions and permissions are framework concerns or your invention. A weak answer means custom token handling. A year later you own a security surface you never wanted and cannot audit. Background jobs. Tests whether there is a supported way to do work offthe request path. A weak answer is a thread started inside a handler. A year later work vanishes on every deploy and nobody notices until a customer complains. Config. Tests whether configuration is typed, environment driven and validated at start up. A weak answer is scattered environment reads with silent defaults. A year later a missing variable fails at three in the morning inside a rare code path instead of at boot. Production server. Tests whether the development server is honestly separated from the production one. A wea