Shared Database Pattern: Definition, Example, and Use Cases

The shared database pattern is a microservices design where multiple services access the same database to share data. This pattern simplifies data consistency but can create tight coupling between services and reduce independence.

How It Works

Imagine a group of friends sharing a single notebook to write down their plans. Each friend can read and write in the same notebook, so everyone sees the latest updates immediately. This is similar to the shared database pattern where multiple microservices use one common database to store and retrieve data.

In this pattern, instead of each service having its own separate database, all services connect to the same database schema. This makes it easy to keep data consistent because there is only one source of truth. However, it also means that services depend on the same database structure, which can limit their ability to change independently.

Example

This example shows two simple microservices accessing the same database table to read and write user information.

python

import sqlite3

# Shared database file
DB_FILE = 'shared_users.db'

# Initialize database and create table if not exists
def init_db():
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute('''CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)''')
    conn.commit()
    conn.close()

# Service A: Adds a user
def service_a_add_user(user_id, user_name):
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute('INSERT INTO users (id, name) VALUES (?, ?)', (user_id, user_name))
    conn.commit()
    conn.close()

# Service B: Reads all users
def service_b_get_users():
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute('SELECT * FROM users')
    users = cursor.fetchall()
    conn.close()
    return users

# Demo
init_db()
service_a_add_user(1, 'Alice')
service_a_add_user(2, 'Bob')
users = service_b_get_users()
print('Users in shared database:', users)

Output

Users in shared database: [(1, 'Alice'), (2, 'Bob')]

When to Use

The shared database pattern is useful when you want to keep data consistent easily and your microservices are tightly related or managed by the same team. It works well for small projects or when quick development is more important than full independence.

However, it is not ideal for large, complex systems where services need to evolve separately or scale independently. In those cases, separate databases per service or event-driven patterns are better.

Real-world use cases include legacy systems migrating to microservices or simple applications where data sharing is critical and service independence is less important.

Key Points

• Multiple microservices share one common database.
• Easy to keep data consistent across services.
• Services become tightly coupled to the database schema.
• Limits independent service evolution and scaling.
• Best for small or simple systems with shared data needs.

Key Takeaways

The shared database pattern means multiple services use the same database to share data.

It simplifies data consistency but creates tight coupling between services.

Use it for small projects or when quick data sharing is needed.

Avoid it for large systems needing independent service scaling and evolution.

Consider separate databases or event-driven patterns for better service independence.