Database per Service and Querying Across Services

Each service owns its data

In microservices, each service owns its data, and other services access it only through the service's API or events: database per service (which can mean a separate schema on a shared server, or a separate database). The shared database anti-pattern, where several services read and write the same tables, couples their deployments and schema changes and defeats independence. Owning data raises a question: how do you answer queries that span services, such as "orders with customer names and product titles"? Options: API composition (a composer calls each service and joins in memory; simple but slower and fragile with many calls); data duplication via events (the orders service keeps the customer name it needs, updated from CustomerRenamed events); and CQRS read models that subscribe to events from many services and build a query-friendly view. Accept that data across services is eventually consistent.

API composition for an order details page

Calls run concurrently, and a missing optional piece does not fail the page.

async def order_details(order_id):
    order = await orders_api.get(order_id)                       # required
    customer_task = customers_api.get(order["customerId"])
    products_task = catalogue_api.batch_get([i["sku"] for i in order["items"]])
    shipping_task = fulfilment_api.tracking(order_id)

    customer, products, shipping = await asyncio.gather(
        customer_task, products_task, shipping_task, return_exceptions=True
    )
    return {
        "order": order,
        "customer": None if isinstance(customer, Exception) else customer,
        "products": {} if isinstance(products, Exception) else products,
        "tracking": None if isinstance(shipping, Exception) else shipping,   # degrade gracefully
    }

Separate ledgers per department

Each department keeps its own ledger. If finance wants a combined report, it asks each department for figures or keeps a summary book updated from their monthly reports; it never writes in another department's ledger.

त्वरित जाँच: Why is a shared database between services considered an anti-pattern?

• Databases cannot handle multiple connections
• Schema changes and deployments become coupled across services, defeating independence
• It is always slower than API calls
• It prevents backups