Exercise 3: Why a Real Gateway Needs Service Discovery Internally — Possible Solution
====================================================================

WHY A HARDCODED-ADDRESS GATEWAY WOULD BREAK THE SAME WAY
------------------------------
This chapter's own ApiGateway is constructed with direct references to
order_service, inventory_service, and review_service objects - in a
real deployed system, those would be network addresses, not in-process
Python objects. If the gateway captured those addresses once at its
own startup (exactly the pattern this chapter's own hardcoded client
used), then whenever ANY of the three backend services redeployed or
rescaled - a genuine event under Chapter 1's own horizontal scaling -
the gateway's own calls to that service would start failing, exactly
matching this chapter's own verified hardcoded-client result (call
succeeds: False). The gateway would keep aggregating the OTHER two
services correctly while silently failing to reach the one that moved,
producing incomplete or broken aggregated responses to every client
that hit it.

WHY AGGREGATION ALONE DOESN'T SOLVE THIS
------------------------------
This chapter's own aggregation finding (the 2.53x-3.12x speedup) is
entirely about REDUCING HOW MANY ROUND TRIPS a client pays for - it
says nothing about whether any individual round trip the gateway makes
internally will actually reach a live service. Aggregation and address
correctness are independent concerns: a gateway could aggregate calls
extremely efficiently while every single one of those calls fails,
because it's hardcoded to addresses that don't exist anymore.

WHY A REAL GATEWAY NEEDS DISCOVERY INTERNALLY, NOT JUST AGGREGATION
------------------------------
A production API gateway sits in exactly the position this chapter's
own DiscoveryClient sits in relative to InventoryService - it needs to
look up each backend service's own CURRENT address at the moment of
each call, the same way this chapter's own discovery client correctly
found 10.0.0.9:8080 after InventoryService's own redeploy. Without
that, the gateway inherits the worst of both worlds: it becomes a
single, central point that's ALSO using the exact stale-address pattern
this chapter already verified breaking - meaning a single missed
redeploy at the gateway's own dependency layer could silently degrade
every client request going through it, not just one client's own
requests.

WHY THIS WORKS AS AN ANSWER
------------------------------
The answer connects both of this chapter's own verified findings
directly - showing the gateway's own internal calls are subject to the
exact same address-staleness failure this chapter already demonstrated
for a plain client, and explaining precisely why aggregation (reducing
round-trip count) and discovery (keeping addresses correct) are
solving two genuinely separate problems that a real gateway needs both
of.