Exercise 3: Why redirect() Never Needed a try/except for Analytics — Possible Solution ==================================================================== WHAT CHAPTER 9'S GRACEFUL-DEGRADATION EXAMPLE ACTUALLY DID ------------------------------ Chapter 9's own ResilientGateway called self.review_service.get_reviews() DIRECTLY, inline, as part of building its own response - meaning a failure in that call would propagate straight into ResilientGateway.get_order_page() unless explicitly caught. The try/except was necessary there specifically because the failing dependency was called SYNCHRONOUSLY, in the same call stack, as part of assembling the one response being built. WHAT THIS CAPSTONE'S redirect() ACTUALLY DOES ------------------------------ redirect() calls self.click_queue.publish(short_code) - and publish() (Chapter 6's own ClickEventQueue) does nothing but append short_code to a list. It never calls a handler, never touches the analytics service, never does anything that could raise an exception related to analytics at all. The ACTUAL analytics call - the one that can fail - only happens later, in a completely separate step (circuit_breaker.call(broken_analytics_call, code)), run against events already sitting in the queue, in code that redirect() never executes and has no reference to. THE STRUCTURAL DIFFERENCE, STATED DIRECTLY ------------------------------ Chapter 9's gateway needed a try/except because it made a synchronous call to something that could fail, IN LINE with building its own result. This capstone's redirect() never makes that call at all - Chapter 6's own message-queue pattern (verified in this exact chapter: 21 events queued, 0 processed at the moment of redirect) means the risky call physically doesn't exist in redirect()'s own execution path. There's nothing to catch, because there's nothing there that could throw - the failure-prone code was moved to and isolated in an entirely separate process step (queue processing), not just wrapped defensively. WHY THIS IS A GENUINELY DIFFERENT (AND, HERE, STRONGER) RESILIENCE TECHNIQUE ------------------------------ Graceful degradation (Chapter 9) accepts that a failure CAN reach the critical path and prepares a fallback for when it does. This capstone's own design goes one step further: it structurally prevents the failure from ever being ABLE to reach the critical path at all, by making the risky operation asynchronous and decoupled (Chapter 6) rather than synchronous and defensively wrapped. Both are legitimate resilience strategies, but this chapter's own verified redirect()-stays-untouched result is stronger evidence than a try/except would have been - it shows the failure mode was designed out, not merely caught. WHY THIS WORKS AS AN ANSWER ------------------------------ The comparison is grounded in the actual code from both chapters - Chapter 9's own synchronous ResilientGateway call versus this capstone's own asynchronous ClickEventQueue.publish() - and the answer identifies the specific mechanical reason (no risky call exists in redirect()'s own execution path) rather than only asserting the two approaches are "different."