Exercise 2: Fixing the Shared-Database Anti-Pattern — Possible Solution
====================================================================

THE FIX: SEPARATE STORES, ONE OWNED EXCLUSIVELY BY EACH SERVICE
------------------------------
    orders_db = {'ORD-1': {'total': 100}}
    inventory_db = {'ORD-1': {'product_id': 'PROD-1'}}

    class InventoryServiceProcess:
        def get_order_product(self, order_id):
            return inventory_db[order_id]['product_id']

    class OrderServiceProcess:
        def __init__(self, inventory_service):
            self.inventory_service = inventory_service
        def get_order_summary(self, order_id):
            total = orders_db[order_id]['total']
            product = self.inventory_service.get_order_product(order_id)  # calls the SERVICE, not the store
            return f'Order {order_id}: ${total} for {product}'

OrderServiceProcess no longer touches inventory_db at all - it only
ever calls InventoryServiceProcess's own method, exactly the way
Chapter 1's OrderService called a repository instead of touching
storage directly, and the way this chapter's own genuine microservices
should communicate: through a defined interface, not a shared table.

VERIFYING BEFORE THE RENAME
------------------------------
    before rename: Order ORD-1: $100 for PROD-1

VERIFYING THE SAME RENAME NO LONGER BREAKS OrderServiceProcess
------------------------------
InventoryServiceProcess renames product_id -> sku internally, exactly
like this chapter's own broken example, and ships InventoryServiceProcessV2
with an updated get_order_product() matching the new field name:

    after rename, OrderServiceProcess unchanged, only the injected service swapped:
    Order ORD-1: $100 for PROD-1

OrderServiceProcess's own source code was never touched - only the
injected inventory_service reference was swapped for the updated
version, and OrderServiceProcess kept working correctly throughout.

WHY THIS IS A GENUINE FIX, NOT JUST A RENAME
------------------------------
The bug in this chapter's own original version wasn't the specific
field name - it was that OrderServiceProcess read shared_db directly,
giving InventoryServiceProcess no actual control over its own data's
shape. Here, InventoryServiceProcess's own internal storage format is
free to change in any way at all, as long as its public method
(get_order_product()) keeps returning the same kind of answer -
exactly the interface-vs-implementation boundary this course has built
in every chapter so far.

WHY THIS WORKS AS AN ANSWER
------------------------------
The fix separates the two services' own storage completely and routes
all cross-service reads through a method call rather than a shared
table, and the exact same rename scenario from this chapter is
re-verified to confirm it no longer breaks the other service - proving
the fix addresses the real cause, not just this one symptom.