Production Checklists, Decision Maps, Glossary, and Next Steps

Expert backend engineering is the ability to choose the simplest system that meets evidence-based requirements, preserve correctness as it evolves, and recover when assumptions fail. This reference turns the book into reusable decisions and launch checks. It is not a substitute for threat models, tests, drills, or current primary documentation.

What should you choose first?

Is Redis needed?

Ask in order:

1. What measured problem cannot PostgreSQL or local memory solve?
2. Is the value ephemeral or safely reconstructable?
3. What key, tenant/permission scope, value schema, TTL, and memory bound apply?
4. What invalidates it?
5. What happens when Redis is slow, partitioned, or empty?
6. Does failure open or closed, and why?
7. What telemetry and capacity alarm prove it helps?

If these answers are unclear, do not add Redis yet.

Does this feature need AI?

• Can deterministic code meet quality and cost? Use it.
• Can output be constrained and verified? Prefer those tasks.
• Can an error cause harm or irreversible effect? Require policy and human control or avoid it.
• Is governed context available? Build data foundations first.
• Is there a representative evaluation dataset? Do not ship on impressions.
• Is there a safe provider-outage path? Design it before launch.

Production launch checklist

Product and contracts

• User journeys and negative paths have acceptance tests.
• OpenAPI/events/tool schemas are reviewed and versioned.
• Pagination, idempotency, concurrency, and compatibility are explicit.

Data

• PostgreSQL constraints encode critical invariants.
• Tenant scope exists in schema, queries, cache, jobs, files, retrieval, and exports.
• Migrations pass fresh install, upgrade, load/lock review, and rollback/roll-forward plan.
• Backup and isolated restore meet RPO/RTO.
• Retention, correction, export, and derivative deletion are implemented.

Security

• Threat model covers API, supply chain, AI, MCP, tools, and operators.
• Identity uses standard validation; authorization is resource-specific.
• Secrets are short-lived where possible, rotated, redacted, and absent from artifacts.
• Inputs, files, egress, bodies, time, concurrency, and spend are bounded.
• Consequential tools use exact approval, idempotency, and audit.

Reliability and operations

• Deadlines, retries, breakers, bulkheads, queues, and degraded modes are tested.
• Liveness/readiness/startup mean different truthful things.
• Logs, metrics, traces, SLOs, alerts, dashboards, and runbooks exist.
• Capacity and noisy-tenant tests protect downstream limits.
• Canary, kill switch, full-version rollback, and incident roles are rehearsed.

AI quality

• Provider gateway, prompt, schema, model alias, index, and policy are versioned.
• Offline dataset has normal, slice, failure, abstention, and adversarial cases.
• Retrieval, citations, generation, tools, safety, latency, and cost are measured separately.
• Human review and feedback are meaningful, not ceremonial.
• Online drift and configuration changes are observable.

Incident quick checklist

1. Declare severity, commander, communication channel, and impact.
2. Stabilize: rollback, shed load, disable the feature, revoke credentials, or fail over.
3. Preserve timestamps, traces, audit, version set, and evidence.
4. Communicate facts and next update time.
5. Diagnose using hypotheses and discriminating tests.
6. Recover and verify user, data, security, AI-quality, and cost signals.
7. Reconcile ambiguous jobs/tool effects before retry.
8. Review system causes, assign actions, and verify their effectiveness later.

Glossary

• Adapter: implementation connecting an application port to external technology.
• Aggregate: domain consistency boundary changed as one unit.
• AI run: durable record of one model/workflow operation and its evidence.
• Backpressure: mechanism that slows or rejects producers when consumers are saturated.
• Circuit breaker: control that temporarily stops calls to a failing dependency.
• Context: selected instructions and data supplied to a model for one operation.
• Cursor pagination: continuation based on a stable ordered key rather than an offset.
• Embedding: numeric representation used for similarity operations; not authority or truth.
• Evaluation: reproducible measurement of AI behavior against cases and criteria.
• Fencing token: monotonically increasing token that lets a resource reject a stale lock owner.
• Idempotency: repeated equivalent command produces one intended effect/outcome.
• Inbox/outbox: durable patterns for deduplicating consumed events and publishing committed events.
• MCP: protocol for AI hosts to discover and use server capabilities under host policy.
• Migration: versioned transformation of database schema or data.
• Port: application-owned interface describing a required capability.
• RAG: retrieval of external evidence to support model generation.
• RPO/RTO: maximum tolerable data loss and recovery time.
• SLO: measurable reliability target for a user-visible capability.
• Structured output: model result constrained to an application-owned schema.
• Tenant: isolated customer or organization context.
• Tool: typed capability a model may propose and application policy may execute.
• Trace: correlated record of work across process and service boundaries.
• Unit of work: owner of one atomic transaction across repositories.
• Vector index: search structure for approximate or exact similarity over embeddings.

What is the mastery path after this book?

1. Rebuild Capstone 1 without referring to the implementation.
2. Operate Capstone 2 for several weeks with synthetic traffic and scheduled failures.
3. Publish Capstone 3's evaluation methodology and compare one controlled change.
4. Red-team Capstone 4 with a teammate who did not build it.
5. Contribute a fix, test, or documentation improvement to one dependency you rely on.
6. Read PostgreSQL query plans and production traces weekly.
7. Write ADRs before adding systems; revisit them when triggers fire.
8. Teach one chapter. Teaching reveals unexamined assumptions.

AI Pair-Programmer Prompt

Final exercise

Choose one capstone and conduct a release review with another person. Neither reviewer may accept “it should,” “the framework handles it,” or “the AI understands” as evidence.

Acceptance criteria: every launch claim has reproducible evidence, every accepted risk has an owner and date, and the final architecture contains no component whose purpose or outage behavior is unknown.

Knowledge check

1. What is the default durable database in this book?
2. When is Redis justified?
3. When should an agent replace a workflow?
4. What makes a production claim credible?

---

Answers

1. PostgreSQL.
2. When a measured shared low-latency/ephemeral need, bounded design, and outage policy justify it.
3. Only when adaptive planning produces measured value beyond a workflow while safety and budgets remain bounded.
4. Reproducible evidence such as tests, traces, evaluations, scans, migrations, restores, canaries, and drills.

Completion checklist

• I can justify every component and remove unjustified ones.
• I can produce evidence for launch claims.
• I can recover the system and explain its tradeoffs.
• I have a concrete next mastery project.

Primary references

• FastAPI
• PostgreSQL
• Redis
• OpenTelemetry
• OWASP API Security
• OWASP GenAI Security
• NIST AI RMF