Skip to main content
>_ supraj.dev

Module 7: Enterprise Production & Capstone · 4.25h

01 · UNDERSTAND

Day 45 Theory — Architecture Defense, On-Call Drill and Portfolio Evidence

The final skill is explaining your engineering decisions

A production engineer must be able to defend why the system is designed the way it is, not only show that it runs.

Today you explain trade-offs, respond to an incident scenario, and package evidence that another engineer or interviewer can inspect.

Architecture defense

For every major choice, be able to answer:

  1. What problem were we solving?
  2. What alternatives existed?
  3. Why did we choose this design?
  4. What failure modes remain?
  5. What evidence tells us it is acceptable?

Examples include:

  • custom loop versus LangGraph,
  • single-agent versus multi-agent,
  • RAG retrieval strategy,
  • MCP/A2A boundaries,
  • approval placement,
  • retry and circuit-breaker policy.

On-call drill

An incident drill tests operational reasoning.

A strong response sequence is:

detect -> assess user impact -> stabilize -> investigate -> recover -> verify -> learn

The first objective is not to find the perfect root cause. It is to reduce user harm safely.

Use traces, metrics, logs and runbooks rather than guessing.

Portfolio evidence

A useful portfolio does more than show screenshots.

Include:

  • architecture diagram,
  • concise problem statement,
  • important code paths,
  • test/eval evidence,
  • security controls,
  • deployment instructions,
  • trade-off discussion,
  • known limitations.

Do not claim unsupported scale or “production grade” simply because Docker builds.

What graduation from this course means

You are not expected to memorize every framework API.

You should be able to:

  • learn from official documentation,
  • build a small verified implementation,
  • reason about model/tool/state boundaries,
  • evaluate behavior,
  • secure side effects and data,
  • observe and operate the system,
  • explain your decisions.

Service Desk connection

The Service Desk began as typed deterministic Python and evolved into a measured, retrieval-enabled, tool-using, stateful, interoperable and operable AI system.

On Day 45 the project stops being only a teaching vehicle and becomes evidence you can defend. You should be able to walk another engineer through the architecture, show the tests and evals that support your claims, explain security and reliability boundaries, and describe what you would improve next.

The final principle is:

Frameworks will change. Strong engineering survives: explicit contracts, measured behavior, least privilege, failure-aware design, observability, and the ability to explain why the system works the way it does.

02 · APPLY

Lesson Overview

This is the applied companion for Day 45. Read DAY_45_THEORY.md first for the beginner-first teaching of Architecture Defense, On-Call Drill and Portfolio Evidence. Then use the real service-desk-day-45/ project to trace, run, debug, and explain the concept.

Service Desk Alignment

Day 45 adds Architecture Defense, On-Call Drill and Portfolio Evidence to the running Service Desk. Start with oncall/rollback.py, oncall/simulator.py, core/engine.py, then follow imports and tests to identify the actual runtime path.

Why This Topic Matters

The theory chapter explains why Architecture Defense, On-Call Drill and Portfolio Evidence is needed. Here the goal is evidence: identify where the capability is implemented, what observable behavior changes, and how the repository proves both success and failure behavior.

System Architecture

The implementation boundary for Architecture Defense, On-Call Drill and Portfolio Evidence is the service-desk-day-45/ project. Use its README and tests as the executable architecture map.

Repository Implementation Map

Use the real Day 45 repository, not a fabricated sample, to connect theory to implementation.

Theory concepts to locate:

  • The final skill is explaining your engineering decisions
  • Architecture defense
  • On-call drill
  • Portfolio evidence

Most relevant implementation modules first:

  • service_desk/oncall/rollback.py
  • service_desk/oncall/simulator.py
  • service_desk/core/engine.py

Follow imports/calls from the relevant module and confirm behavior in tests. Record input → mechanism → observable output/state → failure evidence.

Code Walkthrough & Mechanics

Read oncall/rollback.py, oncall/simulator.py, core/engine.py with these theory sections beside you:

  • The final skill is explaining your engineering decisions — locate its implementation and evidence.
  • Architecture defense — locate its implementation and evidence.
  • On-call drill — locate its implementation and evidence.
  • Portfolio evidence — locate its implementation and evidence.
  • What graduation from this course means — locate its implementation and evidence.

For each concept identify the real function/class/protocol boundary, its input/state, its observable result, and the assertion in tests/test_portfolio_defense.py that proves the behavior. If a concept has no implementation or evidence, record that as a gap rather than inventing one.

Common Mistakes & Debugging Guidance

Use the theory—not generic timeout or .env advice—to decide what can fail today.

Failure lens: revisit Portfolio evidence, What graduation from this course means.

  • Reproduce the smallest case that violates one of those expectations.
  • Trace the real Day 45 modules until you find the first incorrect state/output/decision.
  • Use tests/test_portfolio_defense.py as executable evidence.
  • Add a regression test if the failure is not already represented.
  • Fix the smallest responsible boundary and rerun the relevant test before the full suite.

Your debugging explanation must name the topic-specific invariant that failed, not merely say “an exception occurred.”

Practical Lab Instructions

  1. Summarize these theory ideas before opening the implementation:
    • The final skill is explaining your engineering decisions
    • Architecture defense
    • On-call drill
    • Portfolio evidence
  2. Inspect the most relevant real Day 45 modules first:
    • service_desk/oncall/rollback.py
    • service_desk/oncall/simulator.py
    • service_desk/core/engine.py
  3. Inspect the automated evidence:
    • tests/test_portfolio_defense.py
  4. Establish the baseline:
    cd service-desk-day-45
PYTHONPATH=. pytest tests/test_portfolio_defense.py -q
  5. Trace one theory concept through the actual nested modules and tests.
  6. Run one success case and record input → mechanism → observable result.
  7. Exercise one topic-specific failure/boundary case and name the invariant that protects the system.
  8. Re-run the relevant tests and explain theory → implementation → evidence.

Done when: another student can reproduce your trace without relying on an invented sample.

Key Takeaways

  1. Be able to explain The final skill is explaining your engineering decisions and point to its implementation/evidence in Day 45.
  2. Be able to explain Architecture defense and point to its implementation/evidence in Day 45.
  3. Be able to explain On-call drill and point to its implementation/evidence in Day 45.

Knowledge Check & Scenario Questions

  1. Concept: Using The final skill is explaining your engineering decisions, explain the engineering problem Day 45 is solving without naming a framework as the answer.
  2. Mechanism: How does Architecture defense appear in the real project? Start from service_desk/oncall/rollback.py and name the observable state/output/event that changes.
  3. Failure: For On-call drill, describe one incorrect implementation or boundary condition and the evidence you would expect in tests/test_portfolio_defense.py.
  4. Design review: Which assumption in today's design would you verify before reusing this implementation in a different production system?

Official References

03 · EXPLAIN

Interview checkpoint

Explain one design decision from this lesson, the alternative you rejected, and the failure mode or evidence that justified your choice.