Chapter 1 — Computing and service architecture

Chapter 1 — Computing and service architecture

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["1.1 Model the service outcome first"]
  N2["1.2 Separate the planes and boundaries"]
  N3["1.4 Offline lab: compute a conservative dependency c"]
  N4["1.5 Failure and rollback evidence"]
  N5["1.6 Convert a component graph into an outcome contra"]
  N6["1.7 Guided paper lab: predicted impact versus observ"]
  N7["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["1.1 Model the service outcome first"]
  N2["1.2 Separate the planes and boundaries"]
  N3["1.4 Offline lab: compute a conservative dependency c"]
  N4["1.5 Failure and rollback evidence"]
  N5["1.6 Convert a component graph into an outcome contra"]
  N6["1.7 Guided paper lab: predicted impact versus observ"]
  N7["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]

[Learning outcomes and connection]
    |
    v
[1.1 Model the service outcome first]
    |
    v
[1.2 Separate the planes and boundaries]
    |
    v
[1.4 Offline lab: compute a conservative dependency c]
    |
    v
[1.5 Failure and rollback evidence]
    |
    v
[1.6 Convert a component graph into an outcome contra]
    |
    v
[1.7 Guided paper lab: predicted impact versus observ]
    |
    v
[Subject synthesis]
    |
    v
[Worked example] --> [Exercise EX001]

Learning outcomes and connection

The learner will draw a service dependency graph, separate a data path from a control path, identify trust boundaries and use the model to predict which decisions are at risk when a component fails. At technical depth, a diagram must be falsifiable: every arrow needs a producing system, an expected behavior, an owner and a testable observation. The graph will guide Chapter 2's network-source choices and Chapter 3's identity analysis. NIST SP 800-61 Rev. 3 places response within organizational cybersecurity risk management; the particular LLR graph is an original lab model.

1.1 Model the service outcome first

LLR's user outcome is “an authorized patron can see an available study room and reserve it without losing an existing reservation.” That statement is more useful for incident response than “the portal is online.” The portal may render a page while the write path is broken; a backup job may succeed while the restored data would overwrite newer reservations. Separate availability (can a request be served?), correctness (is the returned reservation state right?), authorization (does the requesting principal have the required right?) and auditability (can an owner reconstruct the change?). A healthy front page alone proves none of the other three.

The invented components are: edge, a gateway that receives browser requests; api, the reservation application; idp, an identity service; db, the authoritative reservation store; worker, an approved reminder/synchronization job; and backup, a service that takes versioned copies of db. Treat the names as roles, not hostnames. The dependency rule is “A depends on B if B's failure can prevent A from meeting its stated outcome.” This conservative relation does not mean every B failure will always cause an A outage: caches, fallbacks and degraded modes may exist. A field test must check them.

An arrow edge → api says the edge depends on the API. A failure domain is the set of components a failure might affect under the graph. A blast-radius hypothesis predicts this domain before testing; it is not a measured impact count. If idp becomes unavailable, api and worker may fail authentication-dependent functions, and edge may surface their API failure. backup is not downstream of idp in this graph. If db fails, api, worker, backup and then edge may be affected. These conclusions depend on the assumed arrows. A service owner might show that api can serve read-only cached pages while writes fail, which would refine the graph rather than invalidate the method.

1.2 Separate the planes and boundaries

The request/data path is browser → edge → api → db, with an authorization check through idp. The scheduled path is worker → idp/db, and may issue API requests through a route the diagram has not yet shown. The control path comprises configuration, credentials, deployment permissions and backup/restore approvals. A responder considering an emergency change should map both: disabling one idp principal could stop an unwanted session and the approved worker. Restoring a whole db snapshot could put the portal back online while discarding later legitimate reservations. “Small change” is about scope and dependencies, not just the number of commands.

Mark a trust boundary whenever authority, ownership or data handling changes: browser to edge, edge to api, api/worker to idp, application to db, and production db to backup copy. For each crossing ask: which principal is asserted, how does the receiver verify it, what record is generated, how long is that record retained, and who can retrieve it? Do not assume TLS alone supplies the application principal: it protects a transport channel according to its configuration, while application authorization and audit are separate checks. Chapter 2 will distinguish those observations precisely.

A source of truth is an owner-designated record for a particular decision at a particular time, not a magic system that answers all questions. db may be authoritative for stored reservation values, idp for session status and the change ledger for approval scope. A browser screenshot is an observation of a displayed page. A backup digest checks byte identity of a given copy, not whether the copy has the latest accepted business state. In a case record, write which question each source can answer and one limitation.

1.3 Worked example: a two-component alert

Suppose LLR receives a fictional 12:04 alert: the edge reports HTTP errors and the worker's last run did not finish. It is tempting to name an “edge attack.” The graph says api, idp and db are shared upstream explanations for some combination of these symptoms; the edge itself may be healthy. The two symptoms also could be unrelated. The technical response is to request read-only, owner-approved status for the API, identity dependency and database, using a bounded time window. The responder should not restart or disable anything from this alert alone. A second observation might show edge-to-API timeout while worker reached db normally, which would narrow the failure domain. A green edge health probe would not settle a failing reservation function if it tests only a static page.

Record the model as a hypothesis ledger: observed = edge errors and worker unfinished; inferred = shared dependency possible; discriminators = API request trace, idp availability, db read status, worker error class; authority = owners for each read; action = no production change yet. This prevents a diagram from becoming a story that is treated as fact.

1.4 Offline lab: compute a conservative dependency closure

Use Python 3 with this literal fixture. It reads no files or network resources and changes no system setting. The direction of each set is consumer → producers. downstream(failed) finds consumers whose required producer is in the accumulated affected set. Its output is a potential-impact set under the lab graph, not a measured outage.

dependencies = {
    "edge": {"api"},
    "api": {"idp", "db"},
    "worker": {"idp", "db"},
    "backup": {"db"},
    "idp": set(),
    "db": set(),
}

def downstream(failed):
    affected = {failed}
    while True:
        new = {name for name, producers in dependencies.items()
               if name not in affected and producers & affected}
        if not new:
            return sorted(affected - {failed})
        affected |= new

print("idp:", downstream("idp"))
print("db:", downstream("db"))

The expected first line is idp: ['api', 'edge', 'worker']; the second is db: ['api', 'backup', 'edge', 'worker']. Verify by tracing arrows by hand. A negative control is to remove the edge dependency on api in a copy of the fixture and observe that edge disappears from both closures. That is not proof the real edge is independent; it demonstrates that conclusions are sensitive to an assumed arrow. Restore the original literal fixture after the test. In a real environment, validate each arrow with the owner and a permitted service test before using this graph to authorize containment.

1.5 Failure and rollback evidence

Before any response change, compare three questions: what harm might the current condition cause; what dependencies would the proposed change interrupt; and what observable result would justify keeping or rolling back the change? In LLR, revoking the shared worker principal might stop a suspected unauthorized job, but it can also halt legitimate reminders and reservation synchronization. The response lead can propose the action; identity and service owners must decide the exact principal, duration, alternative and rollback; an authorized operator executes; an observer checks both abuse path and legitimate worker function. The lab deliberately performs none of those steps. A paper plan must leave approval and execution blank until real receipts exist.

1.6 Convert a component graph into an outcome contract

A dependency graph answers “what could depend on what?” An outcome contract answers “what would we need to observe before declaring this service function restored?” Keep these separate. For LLR, the patron must see an available room, pass the appropriate authorization check, submit one reservation and later read the correct accepted state. A healthy gateway tests one path; it cannot establish correct authorization or a durable reservation. A backup inventory can show that copies exist, but not that a particular copy preserves all later legitimate bookings.

Specify the scope of every check: identity, room, interval, route and test environment. If a write is approved for one synthetic patron in a test tenant, the result says only that this path worked for that case. If the later read disagrees with the write, stop the success claim even if HTTP returned a success status. The record should say “one approved read/write scenario passed at time T” rather than “LLR is fully restored.” The distinction protects service users from an apparently healthy front page masking a corrupt write path.

For each arrow in §1.1, add a producer contract: expected output, fallback behavior, owner, evidence source and unknown upstream dependencies. The graph deliberately omits the IdP's dependencies and backup storage details. Mark them unknown rather than hiding them. When an owner later confirms a fallback, version the graph and retain the earlier version that informed the previous decision. A revised diagram is evidence of learning, not permission to rewrite the history of an action.

1.7 Guided paper lab: predicted impact versus observed failure

The following L1-V cards are separate hypothetical inputs; they do not amend the main LLR case or the Chapter 2 trace. Build a three-column worksheet headed observed, predicted by graph and unknown. Predict the graph's possible failure domains first, then reveal one card at a time.

• V1: a static edge probe returns 200; an approved test room read returns an API error; the database owner reports a successful read-only table check. No API-to-DB write outcome or IdP status is supplied.
• V2: a worker monitor reports one unfinished scheduled run; an approved patron test reads a room list; the newest backup copy predates the incident window. No reservation write or isolated restore test is supplied.

Worked result: V1 observes static edge availability and a failing room-read path. The database table check weakens a total database unavailability explanation but does not test the API's query, its authorization decision or a write. V2 observes a worker symptom, one successful read and a recovery-point concern. The worker's own configuration, IdP and database paths remain alternatives. An old backup says little about present patron reads. Neither card proves an attacker or justifies a restart. Request bounded route-specific application and identity evidence for V1; request the job's error category and backup-version metadata for V2. Correct worksheets leave write correctness unknown on both cards.

Now create a graph variant, adding an owner-unconfirmed fallback that lets the API serve cached room lists during a database outage. A listing may continue while writes still fail. Label this hypothetical graph G2; do not confuse it with card V2 or overwrite the original six-node fixture. The exercise shows why closure is a conservative prediction under stated arrows, while restoration is an observed business outcome.

Common errors and limits

• Reversing arrow direction and claiming the producer depends on its consumer. Write the dependency convention beside the graph.
• Treating a conservative closure as an incident impact count. It lists possibilities under assumptions, not observed failures.
• Treating “gateway healthy” as “reservations work.” Probe the user outcome and the write path separately in an approved test.
• Using a backup copy as the whole-business restore target without comparing current legitimate data.
• Inferring one human actor from a service-account name; Chapter 3 will show why this is unsafe.

Exercises — subject 1

EX001 — Service map. Objective: identify decisions supported by each component. Inputs: the six LLR components and the table in §1.1. In a local Markdown table, list consumer, producer, owner, one decision source and one unverified assumption for all six. No system access is needed. Evidence: a map another learner can read without guessing arrow direction. Rubric: 2 = all six, direction and limits correct; 1 = map present but one owner/assumption vague; 0 = no testable map.

EX002 — Failure closures. Objective: reason through propagation. Input: the literal Python fixture in §1.4. Run it offline or trace it by hand; record exact sorted outputs for idp and db, then remove edge → api in a copy and state which output members change. Evidence: original and control outputs with a sentence about what closure does not prove. Rubric: 2 = both exact outputs and correct negative control; 1 = one correct closure; 0 = reversed edges or claimed measured outage.

EX003 — Trust-boundary worksheet. Objective: choose minimally sufficient evidence. Inputs: browser, edge, API, IdP, DB and backup roles. For three distinct crossings, name asserted principal, receiving check, expected record, custodian and one missing/untested field. Use only fictional names. Evidence: three-row worksheet. Rubric: 2 = transport and application authority separated with testable gaps; 1 = boundaries named without field/owner; 0 = “TLS proves the user” or invented collected logs.

EX004 — Change-risk review. Objective: preserve business function during a proposed control. Input: the hypothetical shared worker principal at §1.5. Write a 120–180-word request comparing targeted job pause with principal revocation: harm avoided, service risk, approving roles, expiry, positive/negative verification, rollback owner. Mark all actions proposed. Evidence: paper approval request. Rubric: 2 = both options, distinct rights and checks; 1 = risk named without rollback/test; 0 = claims a real action was performed.

Subject synthesis

A response begins with a service and a falsifiable graph, not an alert label. The offline closure shows what the model predicts; the owner and source checks determine what actually happened. Chapter 2 adds protocol and network evidence so a responder can distinguish a broken path from a guessed cause.

Continue studying — chapter 01 of 18

← Course home · Course chapter index · Chapter 02 →

Continue to the next authored lesson.