Scenario Lab — Scenarios 1–9
1 — The single database problem
Situation: mission-critical service stores all data in one centralized database.
Primary problem: one access dependency. Leading area: Storage & Operations; supporting: continuity, availability, architecture. Roles: Data Architect, Production DBA, service owner.
Best action: assess criticality and whether alternate access, replication/failover, and tested recovery are needed; do not declare centralization inherently wrong.
Weaker: “always distribute.” Centralization can suit restricted/simple use cases.
Changed fact: if restricted data must stay centrally controlled and continuity is satisfied by another tested mechanism, centralization may remain best.
Source: pp. 174–176, 194–197.
2 — Point-of-sale DBMS choice
Situation: proposed technology lacks commit/rollback for POS.
Primary problem: platform does not meet transaction requirements. Supporting: Technology Support, ACID. Roles: architect, DBA/technology specialist, application owner.
Best action: reject/reconsider; choose technology supporting required transaction integrity.
Weaker: select fashionable/cheap platform and bend business requirements around it.
Changed fact: workload becomes highly available, non-transactional and tolerates eventual consistency → BASE-oriented approach may fit.
Source: pp. 176–180.
3 — The convenient Production test
Situation: developer wants a “small” patch tested directly in Production.
Primary problem: environment/change-control violation. Roles: Development/Application DBA, Production DBA, developer/change authority.
Best action: Development → Test/QA → controlled scripted Production promotion.
Weaker: direct Production testing because small/urgent.
Changed fact: if work is an exploratory POC with no release intent, isolated Sandbox may be appropriate—but still not Production.
Source: pp. 182–184, 199–202.
4 — Production data in Development
Situation: regulated customer table copied to Development without review.
Primary problem: protected operational data moved without restrictions. Supporting: Data Security, test-data management, governance. Roles: data owner/steward, security/privacy, DBA/test team.
Best action: stop; classify restrictions; use masked/protected or purpose-built test data.
Weaker: assume non-production automatically means safe.
Changed fact: no restricted fields + policy allows controlled sample → masking may be unnecessary, but normal test-data/environment controls remain.
Source: pp. 182–184, 203–205.
5 — Backups that never restore
Situation: daily backups exist; recovery has never been tested.
Primary problem: recoverability is unproven. Supporting: continuity, SLA, failover/recovery. Roles: Production DBA, operations, continuity owner.
Best action: scheduled restore/recovery tests on appropriate non-production/failover infrastructure; document results.
Weaker: successful backup job counts as sufficient evidence.
Changed fact: restore tests pass, but backups sit on same failure-prone filesystem → priority shifts to separate/off-site protected copies.
Source: pp. 194–197.
6 — Capacity surprise
Situation: estimate counts table data but not indexes, logs, mirrors, or growth.
Primary problem: incomplete storage planning. Roles: DBA/NSA, architect, service owner.
Best action: model data + indexes + logs + redundancy + growth; monitor thresholds.
Weaker: wait for exhaustion and buy emergency capacity.
Changed fact: capacity is ample but only month-end response collapses → usage/performance analysis, not more storage.
Source: pp. 193–199.
7 — Month-end slowdown
Situation: service performs normally except predictable month-end collapse.
Primary problem: time-based peak usage pattern. Roles: Production DBA, application owner, operations.
Best action: measure peak; plan capacity/workload scheduling; move heavy jobs to valleys; tune identified bottlenecks.
Weaker: immediate redesign/denormalization without evidence.
Changed fact: slowdown begins after massive inserts/deletes with stale optimizer statistics → statistics/plan investigation becomes first step.
Source: pp. 193–203.
8 — Federation without copying
Situation: three autonomous databases must appear as one without duplicating source data.
Primary problem: unified access while preserving autonomy. Roles: Data Architect, DBAs, source owners.
Best action: federated architecture mapping/presenting a combined view.
Weaker: physically merge/copy sources solely to get a common view.
Changed fact: components no longer require autonomy and must be centrally controlled → non-federated distributed architecture.
Source: pp. 174–176.
9 — OLTP on a column store
Situation: interactive system frequently reads/writes whole rows; team chooses column orientation because analytics are fast.
Primary problem: storage layout mismatches workload. Roles: architect, technology specialist, application owner.
Best action: evaluate/prefer row-oriented layout for OLTP-like access pattern.
Weaker: optimize for unrelated analytics.
Changed fact: workload becomes read-heavy analysis scanning a few columns across millions of rows → column orientation becomes stronger.
Source: pp. 180–186.