# OrderService team can:
class Order(Base):
    __tablename__ = "orders"  # Their own table, their own schema
    
    id: UUID
    user_id: UUID  # Just an ID, not a FK to users table!
    status: OrderStatus
    # ... can change this schema without talking to UserService team

# Deploy without coordination
# Scale database independently (Orders need more IOPS than Users)
# Choose optimal DB tech (Orders → Postgres, Products → MongoDB)

# The business wants: "Show order history with user details"
# Database per service means: TWO API calls + data joining in code

class OrderController:
    async def get_orders_with_users(self, page: int) -> list[OrderWithUser]:
        # Step 1: Get orders from OrderDB
        orders = await self.order_repo.get_page(page)
        
        # Step 2: Collect unique user IDs
        user_ids = list({o.user_id for o in orders})
        
        # Step 3: Batch fetch from UserService (HTTP round trip!)
        users = await self.user_client.get_users_by_ids(user_ids)
        user_map = {u.id: u for u in users}
        
        # Step 4: Join in application code
        return [
            OrderWithUser(order=o, user=user_map.get(o.user_id))
            for o in orders
        ]

# Scenario: Place an order (deduct inventory + create order record)
# These are in different services/databases

# Option 1: Two-Phase Commit (2PC)
# Pros: ACID compliance
# Cons: 2PC is slow, complex, and can leave you in limbo

# Option 2: Saga Pattern
async def place_order_saga(order_data: OrderCreate) -> Order:
    # Step 1: Create order (PENDING)
    order = await order_service.create(order_data, status=PENDING)
    
    try:
        # Step 2: Reserve inventory
        reservation = await inventory_service.reserve(order.items)
        
        # Step 3: Process payment
        payment = await payment_service.charge(order.total, order.user_id)
        
        # Step 4: Confirm everything
        await order_service.confirm(order.id)
        await inventory_service.confirm_reservation(reservation.id)
        
        return order
        
    except InventoryError:
        # Compensate
        await order_service.cancel(order.id, reason="out_of_stock")
        raise
    
    except PaymentError:
        # Compensate both
        await inventory_service.release_reservation(reservation.id)
        await order_service.cancel(order.id, reason="payment_failed")
        raise
    
    except Exception:
        # Handle partial failures...
        # This is where it gets really complicated

# OrderService publishes events
class OrderPlacedEvent(BaseModel):
    order_id: UUID
    user_id: UUID
    user_email: str  # Denormalized for read performance!
    user_name: str   # Denormalized!
    items: list[OrderItem]
    total: Decimal
    timestamp: datetime

# OrderDashboardService maintains a denormalized read model
class OrderDashboardProjection:
    async def on_order_placed(self, event: OrderPlacedEvent):
        # Store denormalized view for fast queries
        await self.db.execute("""
            INSERT INTO order_dashboard 
                (order_id, user_id, user_email, user_name, total, status, created_at)
            VALUES 
                ($1, $2, $3, $4, $5, 'pending', $6)
        """, event.order_id, event.user_id, event.user_email, 
            event.user_name, event.total, event.timestamp)
    
    async def on_user_name_changed(self, event: UserNameChangedEvent):
        # Update denormalized data when source changes
        await self.db.execute("""
            UPDATE order_dashboard SET user_name = $1
            WHERE user_id = $2
        """, event.new_name, event.user_id)

# Traditional approach
class Order(Base):
    status = "shipped"  # Only current state

# Event sourcing approach  
events = [
    OrderCreated(timestamp="09:00", user_id="u1", items=[...]),
    PaymentProcessed(timestamp="09:01", amount=99.99),
    WarehousePicked(timestamp="10:30", warehouse_id="w1"),
    Shipped(timestamp="14:00", tracking_number="TRACK123"),
]
# Current state is derived by replaying events

# This is NOT microservices with DB isolation
class OrderService:
    def get_order_with_details(self, order_id: UUID):
        # Services sharing connection strings to each other's DBs!
        with shared_db.connect() as conn:
            return conn.execute("""
                SELECT o.*, u.name, i.stock_count
                FROM orders_schema.orders o
                JOIN users_schema.users u ON o.user_id = u.id
                JOIN inventory_schema.items i ON o.item_id = i.id
                WHERE o.id = ?
            """, order_id)
# This is a distributed monolith — worst of both worlds

# Never create chains longer than 2 hops
OrderService → UserService → ProfileService → AddressService

# This creates:
# - Cascading failures (one failure brings down orders)
# - High latency (each hop adds ~50ms)
# - Tight coupling through dependency chain