Exercise 2: Recommendations Given a Bigger Pool Than the Original Shared Total — Possible Solution ==================================================================== THE SETUP ------------------------------ recommendations_pool = Pool(size=4) # up from this chapter's own 3 checkout_pool = Pool(size=2) # unchanged Combined total capacity: 4 + 2 = 6 - one MORE than the original shared pool's own capacity of 5 from this chapter's own first (non-bulkhead) scenario. RESULTS ------------------------------ recommendations acquired all 4 of its own pool: True recommendations 5th request (own pool exhausted): False checkout using its own separate pool - acquired: True Recommendations correctly filled and then exhausted its own larger 4-connection pool. Checkout's own request still succeeded, completely unaffected by recommendations' own pool size or its own exhaustion. WHY CHECKOUT STAYS UNAFFECTED REGARDLESS OF RECOMMENDATIONS' OWN POOL SIZE ------------------------------ This confirms bulkheading's own core guarantee doesn't depend on the specific sizes chosen for each pool - checkout_pool.acquire() only ever checks checkout_pool's own in_use count against checkout_pool's own size. Nothing about recommendations_pool - whether it's sized at 3 (this chapter's own original test) or 4 (this exercise) - appears anywhere in that check. Making recommendations' own pool BIGGER doesn't create any new risk to checkout, because the isolation itself, not the specific numbers, is what protects checkout. WHY THE 4+2=6 > 5 COMPARISON IS A DELIBERATE, INSTRUCTIVE DETAIL ------------------------------ Under the ORIGINAL shared-pool scenario, the pool's own total capacity was 5 - meaning even a well-behaved recommendations service using slightly MORE connections than that original total would have been impossible without directly taking capacity away from checkout, since they were drawing from the same 5-connection budget. With bulkheading, recommendations can be given 4 connections of its own, checkout 2 of its own, and the combined total (6) can EXCEED what the original shared pool ever offered - because bulkheading isn't about a fixed total budget being divided more cleverly, it's about each dependency having its own dedicated, non-negotiable allocation. WHY THIS WORKS AS AN ANSWER ------------------------------ The pool sizes are changed specifically to test whether checkout's own protection depends on relative pool sizing, using this chapter's own unmodified Pool class, and the result is verified directly rather than assumed to hold - with the 4+2>5 comparison used deliberately to show bulkheading isn't just repartitioning a fixed total.