Schema Design for Microservices

Apply the database-per-service pattern to ensure loose coupling between microservice domains.

In this lesson, you will learn how to implement the "database-per-service" pattern to decouple your microservices and ensure independent scalability.

The Problem with Shared Databases

When you first start building microservices, it is tempting to use a single, massive database for all your services. However, this creates a "distributed monolith." If your OrderService and InventoryService share the same tables, a change to the schema for one service might inadvertently break the other. Tight coupling at the database level defeats the purpose of microservices: the ability to deploy and evolve components independently.

Applying Database-per-Service

The database-per-service pattern dictates that each microservice must own its own private database. Other services are strictly forbidden from accessing those tables directly. Instead, they must communicate through defined APIs.

A Concrete Illustration

Imagine you have an e-commerce platform. Instead of one global database, you split the schema logically:

Service A: Order Service Owns its own schema, focused only on transactions.

CREATE TABLE orders (
    order_id UUID PRIMARY KEY,
    customer_id UUID,
    total_amount DECIMAL,
    status VARCHAR(50)
);

Service B: Inventory Service Owns a completely separate database instance, oblivious to the orders table.

CREATE TABLE stock_levels (
    sku VARCHAR(255) PRIMARY KEY,
    quantity_available INT,
    warehouse_location VARCHAR(100)
);

By isolating these, the OrderService team can optimize their indexes or migrate their schema (using your knowledge of Schema Versioning Patterns) without worrying about the InventoryService queries. If you need data from both, you don't perform a JOIN across databases. Instead, you coordinate via events or service calls, maintaining loose coupling.

This approach also allows you to choose the best storage engine for the job—perhaps using a time-series database for your logs and a relational database for your financial transactions—without forcing every service into the same technology stack. While this makes data consistency slightly more challenging, it adheres to the principles of Eventual Consistency you've already explored, ensuring that your system remains resilient and modular as it scales.

Key Takeaway: Each microservice must own its own dedicated database schema to prevent coupling, ensuring that services can evolve, deploy, and scale independently.