Database per Service Pattern (Microservices)

The Database per Service Pattern is one of the most critical and non-negotiable principles of microservices architecture.

It ensures loose coupling, scalability, autonomy, fault isolation, and clear data ownership by allowing each microservice to manage its own database.

In a true microservices system:

• Services never share databases
• Services never directly access another service’s data store

👉 If microservices share a database, they are not real microservices — they become a distributed monolith.

What Is Database per Service Pattern?

In microservices architecture, each microservice owns its database, and only that service can read or write to it.

• No other service can query its tables
• No shared schemas
• No cross-service joins

One Microservice = One Database (or schema) it fully controls

This rule:

• Protects service independence
• Enables independent evolution
• Prevents distributed monoliths

Why Each Microservice Needs Its Own Database

Each microservice represents a business capability, not just a technical module.

To stay independent, it must own its data completely.

Reasons Each Service Needs Its Own Database:

Independent Development

• Teams can modify schemas without affecting other services
• Faster development cycles

Independent Deployment

• Database changes don’t break other services
• Zero coordination required across teams

Independent Scaling

• High-traffic services scale their databases independently
• No unnecessary resource usage

Clear Data Ownership

• One service is responsible for its data correctness
• No confusion or data corruption

Without database ownership, microservices lose their purpose.

Problems with Shared Databases (Anti-Pattern)

Sharing a database between microservices is one of the most dangerous anti-patterns.

Shared Database Between Services

User Service  ─┐
               ├── SharedDatabase
Order Service ─┘

Problems with Shared Databases:

• Multiple services read/write the same tables
• Schema changes break multiple services
• Tight coupling between teams
• Deployment coordination becomes mandatory
• Scaling becomes impossible at service level
• One database failure impacts multiple services

📌 Shared Database = Distributed Monolith

Even if services are deployed separately, a shared database makes them tightly coupled.

Database per Service – Advantages

Loose Coupling

• Services interact only via APIs or events
• Internal schema changes remain private

Independent Scaling

• Scale databases based on service-specific load

Technology Flexibility

• User Service → MySQL
• Order Service → PostgreSQL
• Analytics Service → MongoDB

Fault Isolation

• Database failure affects only one service
• System remains partially functional

Clear Boundaries

• Enforces Domain-Driven Design (DDD)
• Strong service boundaries

Database per Service – Real-World Example

E-Commerce Microservices System

Each service:

• Owns its database
• Exposes data only through APIs or events

How Services Communicate Without Sharing Databases

Microservices never query each other’s databases.

Allowed Communication Methods:

1. REST / gRPC (Synchronous)

GET <http://user-service/users/{id}>

2. Event-Driven Communication (Recommended)

User Service publishes:

• UserCreatedEvent
• UserUpdatedEvent

Order Service:

• Listens to events
• Stores only required data, not full user records

✔ Loose coupling

✔ High scalability

✔ Better resilience

✔ Eventual consistency

📌 Data is shared by communication, not by database access.

Practical Coding Example (Spring Boot)

User Service – Own Database

Entity

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private String email;
}

Repository

public interface UserRepository extends JpaRepository<User, Long> {
}

Controller

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserRepository userRepository;

    public UserController(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @PostMapping
    public User createUser(@RequestBody User user) {
        return userRepository.save(user);
    }

    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return userRepository.findById(id).orElseThrow();
    }
}

📌 User Service accesses only User DB.

Order Service – Separate Database

Entity

@Entity
@Table(name = "orders")
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long userId;
    private Double amount;
}

Repository

public interface OrderRepository extends JpaRepository<Order, Long> {
}

Controller

@RestController
@RequestMapping("/orders")
public class OrderController {

    private final OrderRepository orderRepository;

    public OrderController(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    @PostMapping
    public Order createOrder(@RequestBody Order order) {
        return orderRepository.save(order);
    }
}

📌 Order Service never accesses User DB.

Data Consistency Challenges

Since each service has its own database, traditional distributed transactions are avoided.

Common Challenges:

• No cross-service joins
• No global ACID transactions
• Temporary data inconsistencies

📌 Microservices rely on eventual consistency, not immediate consistency.

Handling Transactions – Saga Pattern (Intro)

The Saga Pattern manages transactions across multiple microservices.

How Saga Works:

• Transaction is broken into multiple steps
• Each service performs a local transaction
• If one step fails, compensating actions are executed

Example:

1. Order Service → Create Order
2. Payment Service → Process Payment
3. Inventory Service → Reserve Stock
4. If payment fails → Order is cancelled

Best Practices for Data Management

• Never share databases
• Avoid cross-service joins
• Use APIs or events for data exchange
• Design services around business domains
• Keep schemas private
• Prefer asynchronous communication
• Handle failures gracefully
• Use Saga / Outbox patterns

When NOT to Use Database per Service

• Very small applications
• Single-team projects
• Simple CRUD systems
• Early MVP stage

📌 In these cases, a monolith with a single database is better.

Real-World Usage

Companies using Database per Service Pattern:

• Netflix – Each service owns its data
• Amazon – Independent databases per domain
• Uber – Event-driven microservices
• Banking Systems – Accounts, payments, notifications

Conclusion

The Database per Service Pattern is a foundational principle of microservices.

• Enables true service independence
• Improves scalability and resilience
• Prevents distributed monoliths
• Supports domain-driven design

No microservice should ever directly access another microservice’s database.