Database Decomposition

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// Object-Oriented Encapsulation
class BankAccount {
  private balance: number;  // Private state
  
  // Public interface - the only way to interact with state
  public withdraw(amount: number): Result {
    if (amount > this.balance) {
      return Result.InsufficientFunds;
    }
    this.balance -= amount;
    return Result.Success;
  }
}
 
// Microservice Encapsulation
// UserService owns user data - private database
// Public API - the only way other services interact with user data
@Controller('/users')
class UserController {
  @Get('/:id')
  async getUser(@Param('id') id: string): Promise<UserDTO> {
    // Internal database access - hidden from consumers
    const user = await this.userRepo.findById(id);
    // Returns DTO, not database entity
    return this.toUserDTO(user);
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

-- All in the same database, different table prefixes
-- User Service tables (only user service touches these)
user_service_users
user_service_profiles
user_service_preferences
 
-- Order Service tables (only order service touches these)
order_service_orders
order_service_order_items
order_service_order_history
 
-- Product Service tables (only product service touches these)
product_service_products
product_service_categories
product_service_inventory
 
-- Enforcement: Naming conventions + code review
-- Weakness: All services have credentials to all tables

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

-- PostgreSQL schema separation
CREATE SCHEMA user_service;
CREATE SCHEMA order_service;
CREATE SCHEMA product_service;
 
-- User Service has its own user with schema access
CREATE USER user_service_app WITH PASSWORD 'xxx';
GRANT USAGE ON SCHEMA user_service TO user_service_app;
GRANT ALL ON ALL TABLES IN SCHEMA user_service TO user_service_app;
-- No access to other schemas
 
-- Tables are namespace-isolated
CREATE TABLE user_service.users (...);
CREATE TABLE order_service.orders (...);
 
-- Cross-schema references are possible but should be avoided
-- The database doesn't prevent: SELECT * FROM order_service.orders
-- (if user has broader access by mistake)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

AWS RDS Cluster
├── user-service-db          ← PostgreSQL database
│   └── Credentials: user-service-app/xxx
│   └── Tables: users, profiles, preferences
│
├── order-service-db         ← PostgreSQL database
│   └── Credentials: order-service-app/yyy
│   └── Tables: orders, order_items
│
└── product-service-db       ← PostgreSQL database
    └── Credentials: product-service-app/zzz
    └── Tables: products, categories
 
Pros:
- Complete logical isolation
- Independent credentials and permissions
- Some shared operational tooling
 
Cons:
- Still share underlying compute/storage
- Resource contention still possible

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Service Databases (Complete Isolation):
 
User Service
└── Primary: RDS PostgreSQL (us-east-1)
└── Replica: RDS PostgreSQL (us-west-2)
 
Product Service
└── Elasticsearch Cluster (for search)
└── Redis Cluster (for caching)
 
Order Service
└── RDS Aurora PostgreSQL (ACID transactions)
 
Session Service
└── ElastiCache Redis Cluster
 
Analytics Service
└── Amazon Redshift (OLAP workloads)
 
Each service:
- Owns infrastructure completely
- Scales independently
- Uses optimal technology for workload
- No shared resources whatsoever

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

┌─────────────────────────────────────────────────────────────────────┐
│                     E-Commerce Platform                              │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   User Service ─────────────── PostgreSQL                           │
│   │                             ↑ ACID for user data                │
│   │                             ↑ Complex profile queries            │
│   │                                                                 │
│   Session Service ──────────── Redis                                │
│   │                             ↑ Sub-millisecond session lookups   │
│   │                             ↑ Auto-expiration (TTL)             │
│   │                                                                 │
│   Product Catalog ─────────── Elasticsearch + PostgreSQL           │
│   │                             ↑ Elasticsearch: Full-text search   │
│   │                             ↑ PostgreSQL: Source of truth       │
│   │                                                                 │
│   Order Service ───────────── PostgreSQL (Aurora)                   │
│   │                             ↑ Strong consistency for orders     │
│   │                             ↑ ACID transactions                 │
│   │                                                                 │
│   Shopping Cart ───────────── Redis Cluster                         │
│   │                             ↑ High-speed temporary storage      │
│   │                             ↑ Automatic expiration              │
│   │                                                                 │
│   Recommendations ─────────── Neo4j + Redis                         │
│   │                             ↑ Neo4j: Graph of user-product      │
│   │                             ↑ Redis: Recommendations cache      │
│   │                                                                 │
│   Analytics Service ───────── ClickHouse / Redshift                 │
│   │                             ↑ OLAP for business intelligence    │
│   │                             ↑ Columnar storage for aggregations │
│   │                                                                 │
│   Metrics & Monitoring ────── InfluxDB / Prometheus                 │
│                                 ↑ Time-series optimized             │
│                                 ↑ Efficient downsampling            │
└─────────────────────────────────────────────────────────────────────┘

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Black Friday traffic pattern:
 
Product Service Database:
- Read traffic: 100x normal (browsing product pages)
- Scaling action: Add 5 read replicas
- Cost impact: $500/day temporary increase
- Other services: Unaffected
 
Order Service Database:
- Write traffic: 20x normal (checkout surge)
- Scaling action: Vertical scale to larger instance
- Cost impact: $200/day temporary increase
- Other services: Unaffected
 
Session Service Database:
- Read/write traffic: 50x normal
- Scaling action: Add Redis cluster nodes
- Cost impact: $100/day temporary increase
- Other services: Unaffected
 
User Service Database:
- Traffic: 2x normal (login/signup)
- Scaling action: None needed
- Cost impact: $0
- Other services: Unaffected
 
Total scaling: Precise, targeted, cost-efficient

1
2
3
4
5
6
7
8
9
10
11
12
13
14

-- Easy with shared database:
SELECT 
  o.id, o.total, o.created_at,
  u.name, u.email,
  p.name as product_name
FROM orders o
JOIN users u ON o.user_id = u.id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE o.status = 'pending';
 
-- With database per service:
-- ??? This query is impossible
-- Data lives in three separate databases

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// With shared database - single transaction
await db.transaction(async (tx) => {
  await tx.orders.create({ userId, items });
  await tx.inventory.decrementStock(items);
  await tx.users.updateLoyaltyPoints(userId, points);
  await tx.payments.recordPayment(orderId, amount);
});
// Either all succeed or all rollback - simple
 
// With database per service - distributed operation
const orderId = await orderService.createOrder({ userId, items });
await inventoryService.reserveStock(orderId, items);
// If inventory reservation fails, how do we rollback the order?
await userService.addLoyaltyPoints(userId, points);
// If loyalty points fails, do we release inventory?
await paymentService.processPayment(orderId, amount);
// If payment fails, do we rollback everything?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// Order Service needs user data for order processing
class OrderService {
  constructor(private userServiceClient: UserServiceClient) {}
  
  async createOrder(userId: string, items: OrderItem[]): Promise<Order> {
    // Fetch user data via API
    const user = await this.userServiceClient.getUser(userId);
    
    if (!user.isActive) {
      throw new Error('User account is not active');
    }
    
    // Use user data for order creation
    const order = await this.orderRepository.create({
      userId: user.id,
      shippingAddress: user.defaultAddress,
      email: user.email,  // Denormalized for this order
      items,
    });
    
    return order;
  }
}
 
// UserServiceClient abstracts the API call
class UserServiceClient {
  private baseUrl = 'http://user-service:8080';
  
  async getUser(userId: string): Promise<User> {
    const response = await fetch(`${this.baseUrl}/users/${userId}`);
    if (!response.ok) {
      throw new UserServiceError(response.status);
    }
    return response.json();
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

// User Service publishes events when user data changes
class UserService {
  async updateUser(userId: string, updates: UserUpdate): Promise<User> {
    const user = await this.userRepository.update(userId, updates);
    
    // Publish event for interested services
    await this.eventBus.publish('user.updated', {
      userId: user.id,
      email: user.email,
      name: user.name,
      defaultAddress: user.defaultAddress,
      updatedAt: new Date(),
    });
    
    return user;
  }
}
 
// Order Service maintains a local copy of user data
class OrderServiceUserConsumer {
  @Subscribe('user.updated')
  async handleUserUpdated(event: UserUpdatedEvent) {
    // Upsert local copy of user data needed by Order Service
    await this.localUserCache.upsert({
      userId: event.userId,
      email: event.email,
      name: event.name,
      defaultAddress: event.defaultAddress,
      lastSyncedAt: new Date(),
    });
  }
}
 
// Order Service uses local cache for most operations
class OrderService {
  async createOrder(userId: string, items: OrderItem[]): Promise<Order> {
    // Fast local lookup - no network call
    const userCache = await this.localUserCache.get(userId);
    
    if (!userCache) {
      // Fallback to API if cache miss
      const user = await this.userServiceClient.getUser(userId);
      await this.localUserCache.upsert(user);
    }
    
    // Use cached data
    return this.orderRepository.create({
      userId: userCache.userId,
      shippingAddress: userCache.defaultAddress,
      email: userCache.email,
      items,
    });
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// User Service owns the user's address book
interface UserService {
  // Current addresses the user manages
  addresses: Address[];            // Owned by User Service
  defaultAddressId: string;        // Owned by User Service
  
  // CRUD operations
  addAddress(address: Address): Promise<Address>;
  updateAddress(id: string, updates: Address): Promise<Address>;
  deleteAddress(id: string): Promise<void>;
  setDefaultAddress(id: string): Promise<void>;
}
 
// Order Service owns the shipping address *on an order*
interface OrderService {
  // This is a snapshot, not a reference
  shippingAddress: OrderAddress;   // Owned by Order Service
  billingAddress: OrderAddress;    // Owned by Order Service
  
  // When order is created, address is COPIED, not referenced
  async createOrder(userId: string, addressId: string, items: Item[]) {
    // Fetch current address from User Service
    const address = await userService.getAddress(userId, addressId);
    
    // Store a copy - this never changes, even if user updates address later
    return this.orderRepo.create({
      userId,
      shippingAddress: {
        street: address.street,
        city: address.city,
        country: address.country,
        postalCode: address.postalCode,
      },
      items,
    });
  }
}