Chapter 2 — Computing systems
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes and connection"]
N1["2.1 Layers from hardware to service"]
N2["2.2 Dependencies and failure domains"]
N3["2.3 How failure alters evidence"]
N4["2.4 State, caches and replication"]
N5["2.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["2.1 Layers from hardware to service"]
N2["2.2 Dependencies and failure domains"]
N3["2.3 How failure alters evidence"]
N4["2.4 State, caches and replication"]
N5["2.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX004"]
[Learning outcomes and connection]
|
v
[2.1 Layers from hardware to service]
|
v
[2.2 Dependencies and failure domains]
|
v
[2.3 How failure alters evidence]
|
v
[2.4 State, caches and replication]
|
v
[2.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes and connection
You will be able to (1) describe a service as layers of hardware, operating system, processes, services and storage; (2) draw a dependency map and mark failure domains; (3) explain how a failure in one component changes the evidence produced by another; and (4) choose where to look first when a symptom appears. Chapter 1 gave you the language of sets and implications; here you apply it to systems whose behaviour responders must interpret. Chapter 3 then teaches you to write small programs that read the records these systems produce.
2.1 Layers from hardware to service
A user never sees a server; they see a service, such as "book an appointment". Underneath it are layers. Hardware (or a virtual machine presented as hardware) supplies CPU, memory, storage and network interfaces. The operating system schedules processes, enforces user permissions and writes many of the logs responders rely on. A service is a long-running process (or group of processes) that listens for requests, such as a web server or database engine. Storage holds state: files, database tables, object stores, and backups. Each layer has its own clock, its own identifiers and its own logs. An incident question such as "who changed this record?" may need an application log (which user), a database log (which statement), an operating-system log (which process) and an identity log (which sign-in) — and each may describe the same event differently.
2.2 Dependencies and failure domains
A dependency exists when component A cannot do its job unless B works. Dependencies can be synchronous (the API waits for the identity provider to validate a token) or asynchronous (a queue delivers reminders later). A failure domain is the set of components that fail together because they share something: a power feed, a hypervisor, a cloud region, a database cluster, a single administrator account. Drawing failure domains is a resilience skill and an investigative one. If two "independent" logs share a storage volume that filled up, both will show a gap at the same time; their agreement is not independent corroboration.
2.3 How failure alters evidence
Systems record what they observe, and they observe through their dependencies. When the identity provider is slow, the API may log authentication timeouts that look like failed logins. When a disk is full, the operating system may stop writing audit events while the application keeps running, producing a period in which actions occur but leave no trace. When a load balancer terminates TLS, the application sees the balancer's address, not the client's, unless a forwarding header is recorded — and that header can be forged by a client if the application trusts it blindly. Responders must therefore ask, for every record: which component wrote this, through which dependencies did it learn the fact, and what would it have written if a dependency had failed?
2.4 State, caches and replication
Many services keep copies of data: caches for speed, replicas for availability, backups for recovery. Copies diverge in time. A replica may lag the primary by seconds or hours; a cache may serve a value that the database already changed. For response this has two consequences. Evidence collected from a replica may not show the latest malicious change. And restoration from a copy (Chapter 26) must account for what that copy did or did not contain.
In the Harbourline Booking map the API reads from the replica, so a patient record changed on the primary a few seconds earlier may still appear in its old form to staff. An analyst who exports from the replica during an incident should record its replication lag at that moment. Otherwise a later comparison with the primary will show differences that look like tampering but are only delay between two copies of the same data.
2.5 Worked example (synthetic): Harbourline Booking
Fictional system. Harbourline Booking has four components: an identity provider (IdP) that issues session tokens; a booking API that validates tokens and reads/writes appointments; a PostgreSQL-style database with one primary and one read replica; and a reverse proxy that terminates TLS. The API and database share one hypervisor host, HV-2.
Dependency map (A → B means A needs B): Proxy → API; API → IdP (token validation); API → DB primary (writes) and DB replica (reads); nightly backup job → DB primary.
Failure domains: {API, DB primary, DB replica} share HV-2; IdP is a separate cloud service.
Scenario: on a Tuesday the IdP has a 12-minute partial outage. Effects on evidence: the API logs 340 "authentication failed" events — not credential guessing but validation timeouts; the IdP's own sign-in log shows a gap; the proxy shows normal request volume. An analyst who reads only the API log might report a password-spraying attack. The dependency map predicts the pattern instead: failures in the API that coincide with an IdP gap and normal proxy volume point to the dependency, not to an attacker. The correct next check is bounded and cheap: compare the API failure reasons (timeout versus bad credential) and the IdP status history for the window.
A second scenario shows a failure domain. If HV-2 runs out of disk, the API, primary and replica may all stop logging at once. Three silent logs are then one gap, not three independent observations of quiet.
2.6 Practical activity
Choose a service you use (a university portal, for instance) and draw, from public information only, its likely layers and dependencies. Mark one failure domain and write two sentences: what fails if it fails, and which logs would go quiet or become misleading. Do not probe or scan the real service; this is a reasoning exercise.
Keep the map to one page and mark each arrow as synchronous or asynchronous, because an asynchronous dependency fails late and quietly while a synchronous one fails at once and loudly. Then swap maps with a classmate and ask them to find a failure domain you missed, such as a shared single sign-on provider or one administrator who manages everything. Note which of your assumptions came from public documentation and which were guesses.
2.7 Common errors and limits
- Treating logs from components in the same failure domain as independent corroboration.
- Reading authentication failures as attacks without checking dependency health.
- Forgetting that proxies and NAT change the apparent source address.
- Assuming a replica or cache shows current state.
- Over-detailed maps: the useful map shows the dependencies that change decisions; a full inventory belongs to asset management (see the technologist course).
One limit is inherent. Public information rarely reveals real dependencies, so a map drawn from outside is a hypothesis to be confirmed with the system owner before it guides an investigation. Maps also age: a component moved to a new host breaks the failure domains you marked. Date every map and record who confirmed it, so that a responder knows how far to trust the picture during an incident.
Exercises — chapter 2
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX004 — Dependency map. Inputs: a synthetic clinic reminder service: a scheduler reads appointments from the database and sends messages through an external SMS gateway; staff sign in through the IdP to edit templates. Steps: draw the map; mark at least one failure domain; state which component's log would show a gateway outage. Rubric: 3 = correct directions, plausible failure domain, correct log source with reasoning; 2 = one direction wrong; 1 = list of components only; 0 = none.
EX005 — Evidence under failure. Inputs: the Harbourline map in §2.5; the database primary's disk filled for 40 minutes, during which the API kept accepting writes that then failed. Steps: predict what the API log, database log and proxy log would each show; state one wrong conclusion an analyst might draw. Rubric: 3 = all three predictions plausible and mutually consistent, wrong conclusion named; 2 = one prediction weak; 1 = generic; 0 = none.
EX006 — Address provenance. Inputs: the API records the client address from an X-Forwarded-For header set by the proxy. Steps: explain when this address is trustworthy and when it is not; propose one configuration check that would let a responder rely on it. Rubric: 3 = explains that the header is client-controllable unless the proxy overwrites it and the API accepts it only from the proxy; proposes checking proxy configuration and the API's trusted-proxy list; 2 = partial; 1 = treats header as ground truth; 0 = none.
Chapter synthesis
Model a service as layers and dependencies, mark the failure domains, and ask of every record which component wrote it and what it would have written had a dependency failed. Logs that share a failure domain are not independent witnesses.
Continue studying — chapter 02 of 40
← Chapter 01 · Course chapter index · Chapter 03 →
Continue to the next authored lesson.