Client Server Architecture - Learning Module

Loading content...

0/252

Modern Architectures: Beyond Traditional Client-Server

The Architectural Evolution Continues

The two-tier and three-tier architectures we've explored served as the foundation for enterprise database applications for decades. But the demands of modern software systems—global scale, continuous deployment, polyglot programming, and elastic infrastructure—have driven significant architectural evolution.

The Driving Forces of Change

Cloud Computing: Infrastructure as code, pay-per-use, global distribution
Microservices Movement: Decomposing monoliths into independently deployable services
DevOps Culture: Development and operations merge; deployment automation becomes critical
API Economy: Services expose capabilities via APIs; integration everywhere
Data Growth: Exponential data volumes require new storage and processing paradigms

This page explores how these forces have shaped modern database access architectures. Understanding these patterns is essential for contemporary database work—whether you're building new systems or modernizing legacy applications.

What You Will Master

By the end of this page, you will understand how microservices architecture changes database patterns, the implications of cloud-native and serverless computing for database access, API gateway patterns, event-driven architectures, and how to choose appropriate patterns for specific requirements.

Microservices Architecture and Database Patterns

Microservices architecture decomposes applications into small, independently deployable services, each responsible for a specific business capability. This architectural style has profound implications for database design and access patterns.

The Database-Per-Service Pattern

A fundamental principle of microservices is that each service owns its data exclusively:

Encapsulation: Each service has its own database (or schema); no direct database sharing
Loose coupling: Services communicate via APIs, not shared tables
Independent scaling: Each database can scale according to its service's needs
Technology freedom: Different services can use different database technologies (PostgreSQL, MongoDB, Redis, etc.)

What This Means in Practice

If Order Service needs customer information:

DON'T: Query Customer database directly
DO: Call Customer Service API

This creates network overhead but ensures services can evolve independently.

Converting Mermaid diagram...

Challenges of Microservices Database Patterns

Data Consistency: Without shared transactions, maintaining consistency across services requires careful design (saga pattern, eventual consistency)
Query Complexity: Joins across services require API composition or data duplication
Operational Overhead: Many databases to manage, backup, monitor
Connection Proliferation: Each service needs connection pools; total connections multiply

Distributed Transactions vs. Saga Pattern

Traditional distributed transactions (XA) don't scale well in microservices. The Saga Pattern provides an alternative:

Break distributed operation into local transactions
Each service commits its local transaction
If later step fails, execute compensating transactions to undo earlier steps

Order Saga:
1. Order Service: Create order (PENDING)
2. Payment Service: Reserve funds
3. Inventory Service: Reserve stock
4. Order Service: Confirm order (CONFIRMED)

If step 3 fails:
4c. Payment Service: Release reserved funds (compensating)
5c. Order Service: Cancel order (compensating)

Distributed Systems Are Hard

The CAP theorem applies: you cannot have perfect consistency, availability, and partition tolerance simultaneously. Microservices typically choose availability and partition tolerance, accepting eventual consistency. This trade-off must be understood and communicated to stakeholders—some business operations cannot tolerate eventual consistency.

API Gateway Pattern: The Modern Front Door

In microservices and modern cloud architectures, an API Gateway serves as the single entry point for all client requests. This pattern has evolved from the three-tier model's web server layer into a sophisticated routing and orchestration component.

API Gateway Responsibilities

Request Routing: Direct requests to appropriate backend services based on path, headers, or content
Authentication/Authorization: Validate tokens, enforce access policies before requests reach services
Rate Limiting: Protect backend services from traffic spikes and abuse
Request/Response Transformation: Adapt protocols, aggregate responses, translate formats
Caching: Cache responses for repeated queries
Observability: Centralized logging, tracing, metrics collection

Popular API Gateway Solutions

API Gateway Technology Comparison
Gateway	Type	Strengths	Database Interaction Pattern
Kong	Open Source/Enterprise	Plugin ecosystem, Lua extensibility	Routes to services; no direct DB access
AWS API Gateway	Cloud Managed	Deep AWS integration, serverless-ready	Can trigger Lambda for DB access
Azure API Management	Cloud Managed	Enterprise features, policy engine	Routes to Azure Functions/App Services
Apigee	Enterprise (Google)	Analytics, monetization	API proxying to backend services
Traefik	Cloud-native	Kubernetes-native, auto-discovery	Ingress controller routing to services
nginx/envoy	Reverse Proxy	Performance, control	L7 routing to application tier

Backend for Frontend (BFF) Pattern

A variation where separate gateways serve different client types:

Web BFF: Optimized for browser clients with session handling
Mobile BFF: Optimized for mobile with battery-conscious patterns
Partner BFF: Exposes subset of APIs for external integrators

Each BFF can aggregate data from multiple microservices, reducing client round-trips:

// Mobile BFF: Single endpoint returning composed data
GET /api/mobile/v1/dashboard

// Internally fans out to:
// - Customer Service: Get user profile
// - Order Service: Get recent orders
// - Notification Service: Get unread count
// Returns aggregated response optimized for mobile

GraphQL as API Gateway

GraphQL can function as a sophisticated API gateway, federating data from multiple services:

# Client requests exactly what they need
query {
  order(id: "123") {
    id
    status
    customer {       # Resolved from Customer Service
      name
      email
    }
    items {
      product {      # Resolved from Inventory Service
        name
        inStock
      }
      quantity
    }
  }
}

Gateway Is Not the Database Access Layer

While gateways can aggregate data, they should not query databases directly. Keep database access within services. The gateway routes requests; services access their databases. This preserves encapsulation and allows services to evolve their data schemas independently.

Cloud-Native Database Patterns

Cloud-native architecture embraces ephemeral infrastructure, automated scaling, and managed services. This fundamentally changes how applications interact with databases.

Managed Database Services

Cloud providers offer databases as managed services:

Amazon RDS / Aurora: Managed PostgreSQL, MySQL, SQL Server
Azure SQL Database: Managed SQL Server with serverless options
Google Cloud SQL: Managed PostgreSQL, MySQL, SQL Server
PlanetScale: Managed MySQL with branching
Neon: Managed PostgreSQL with serverless scaling

Benefits of Managed Databases

Automated backups, patching, failover
Push-button scaling (vertical and read replicas)
Built-in monitoring and alerting
High availability configurations included
Reduced operational burden

Cloud-Native Connection Patterns

Cloud environments introduce unique connection considerations:

Cloud Database Connection Patterns

•IAM Authentication: Use cloud identity instead of passwords; tokens rotate automatically (RDS IAM, Cloud SQL IAM)
•Private Networking: Database on private subnet; accessed via VPC peering or private endpoints—never public internet
•Connection Proxy: Cloud-provided proxies (RDS Proxy, Cloud SQL Auth Proxy) handle authentication and pooling
•Secrets Management: Database credentials stored in secrets managers (AWS Secrets Manager, HashiCorp Vault); rotated automatically
•TLS Everywhere: Encrypted connections mandatory; certificates managed by cloud provider
•Regional Replicas: Read replicas in multiple regions for global read performance and disaster recovery

CloudNativeConfig.java
AWS RDS Config
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
// Cloud-Native Database Configuration Examples
 
@Configuration
public class CloudNativeDatabaseConfig {
    
    /**
     * Configuration using AWS RDS Proxy
     * - Handles connection pooling at infrastructure level
     * - Supports IAM authentication
     * - Automatic failover handling
     */
    @Bean
    @Profile("aws")
    public DataSource awsRdsProxyDataSource() {
        HikariConfig config = new HikariConfig();
        
        // Connect to RDS Proxy, not directly to RDS
        config.setJdbcUrl(
            "jdbc:postgresql://my-rds-proxy.proxy-xxxxx.us-east-1.rds.amazonaws.com:5432/appdb"
        );
        
        // IAM Authentication: token-based, auto-rotating
        if (useIamAuth) {
            config.setUsername("iam_user");
            // Password is generated IAM token, not static credential
            config.setPassword(generateRdsAuthToken());
            
            // Token expires after 15 minutes; must handle rotation
            config.setMaxLifetime(900_000);  // 15 minutes
        } else {
            // Credentials from Secrets Manager
            DatabaseSecret secret = secretsManager.getSecret("prod/rds/credentials");
            config.setUsername(secret.getUsername());
            config.setPassword(secret.getPassword());
        }
        
        // Smaller pool - RDS Proxy handles pooling at infrastructure
        config.setMaximumPoolSize(10);
        
        // SSL required for cloud connections
        config.addDataSourceProperty("ssl", "true");
        config.addDataSourceProperty("sslmode", "verify-full");
        
        return new HikariDataSource(config);
    }
    
    /**
     * Generate RDS IAM authentication token
     * Token is short-lived; connection must be established within ~15 min
     */
    private String generateRdsAuthToken() {
        RdsUtilities rdsUtilities = RdsUtilities.builder()
            .region(Region.US_EAST_1)
            .build();
        
        return rdsUtilities.generateAuthenticationToken(
            GenerateAuthenticationTokenRequest.builder()
                .hostname("my-rds-instance.xxxxx.us-east-1.rds.amazonaws.com")
                .port(5432)
                .username("iam_user")
                .build()
        );
    }
    
    /**
     * Configuration for serverless database (Neon, PlanetScale serverless)
     * These scale to zero and auto-scale up
     */
    @Bean
    @Profile("serverless-db")
    public DataSource serverlessDataSource() {
        HikariConfig config = new HikariConfig();
        
        // Serverless databases often use HTTP/WebSocket protocols
        // or standard connections with auto-scaling backend
        config.setJdbcUrl(System.getenv("DATABASE_URL"));
        
        // Smaller pools - serverless DB handles scaling
        config.setMaximumPoolSize(5);
        
        // Faster connection turnover for scale-to-zero databases
        config.setMaxLifetime(300_000);  // 5 minutes
        config.setIdleTimeout(60_000);   // 1 minute
        
        return new HikariDataSource(config);
    }
}

RDS Proxy: The Cloud Connection Pool

AWS RDS Proxy (and equivalents) provide connection pooling at the infrastructure level. This is especially valuable for Lambda functions that would otherwise create new connections with every invocation. The proxy maintains a warm pool of connections to RDS, and Lambda connects to the proxy instead of directly to the database.

Serverless Architecture and Database Challenges

Serverless computing (AWS Lambda, Azure Functions, Google Cloud Functions) executes code without managing servers. Functions spin up on demand, execute, and terminate. This paradigm creates unique challenges for database access.

The Connection Problem

Traditional connection pooling assumes long-running processes:

Pool initializes once, reuses connections
Connections amortize creation cost over many requests

Serverless functions break these assumptions:

Functions may be cold (no existing connections)
Multiple function instances run in parallel
Each instance might create its own connections
Functions terminate, connections dangle or close

Scenario: Lambda function receives 1,000 concurrent requests:

Traditional: 1 pool with 20 connections serves all requests
Serverless (naive): 1,000 function instances each create 1 connection = 1,000 database connections

This quickly overwhelms database connection limits.

Serverless Database Access Strategies
Strategy	How It Works	Pros	Cons
RDS Proxy / Cloud SQL Auth Proxy	External proxy pools connections; functions connect to proxy	Transparent to application; handles pooling	Additional cost; slight latency
Serverless-Native Databases	Neon, PlanetScale, Aurora Serverless v2—designed for serverless	Scale to zero; built-in pooling	Vendor lock-in; learning curve
HTTP/REST Data APIs	Database exposes HTTP API (Aurora Data API)	No persistent connections; simple	Limited features; higher latency
Connection Reuse	Reuse connection across warm invocations	Simple; no external dependencies	Cold starts still create connections
Edge Databases	Database on edge (D1, Turso)	Ultra-low latency; geo-distributed	SQLite-based; limited scale-up

ServerlessDbAccess.ts
AWS Lambda (TypeScript)
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
// Serverless Database Access Patterns
 
import { Client } from 'pg';
import { RDSDataClient, ExecuteStatementCommand } from '@aws-sdk/client-rds-data';
 
/**
 * Pattern 1: Connection Reuse (works with RDS Proxy)
 * Connection created outside handler persists across warm invocations
 */
let connection: Client | null = null;
 
export const withConnectionReuse = async (event: any) => {
    // Reuse existing connection if warm invocation
    if (!connection) {
        connection = new Client({
            host: process.env.RDS_PROXY_ENDPOINT,
            database: 'appdb',
            user: process.env.DB_USER,
            password: process.env.DB_PASSWORD,
            ssl: { rejectUnauthorized: false },
        });
        await connection.connect();
    }
    
    try {
        const result = await connection.query(
            'SELECT * FROM orders WHERE id = $1',
            [event.orderId]
        );
        
        return {
            statusCode: 200,
            body: JSON.stringify(result.rows[0]),
        };
    } catch (error) {
        // Connection might be stale; reset for next invocation
        connection = null;
        throw error;
    }
};
 
/**
 * Pattern 2: Aurora Data API (HTTP-based, no connections)
 * Best for sporadic traffic and simplicity
 */
const rdsData = new RDSDataClient({ region: 'us-east-1' });
 
export const withDataApi = async (event: any) => {
    const command = new ExecuteStatementCommand({
        resourceArn: process.env.AURORA_CLUSTER_ARN,
        secretArn: process.env.AURORA_SECRET_ARN,
        database: 'appdb',
        sql: 'SELECT * FROM orders WHERE id = :orderId',
        parameters: [
            { name: 'orderId', value: { longValue: event.orderId } },
        ],
    });
    
    const result = await rdsData.send(command);
    
    // Data API returns structured response
    const order = mapDataApiResponseToOrder(result.records);
    
    return {
        statusCode: 200,
        body: JSON.stringify(order),
    };
};
 
/**
 * Pattern 3: Serverless-Native Database (Neon, PlanetScale)
 * These databases are designed for serverless workloads
 */
import { neon } from '@neondatabase/serverless';
 
export const withNeonServerless = async (event: any) => {
    // Neon uses HTTP-based driver optimized for serverless
    const sql = neon(process.env.NEON_DATABASE_URL!);
    
    // No connection management needed
    const order = await sql`
        SELECT * FROM orders WHERE id = ${event.orderId}
    `;
    
    return {
        statusCode: 200,
        body: JSON.stringify(order),
    };
};
 
/**
 * Pattern 4: Edge Database (Cloudflare D1, Turso)
 * SQLite-based, runs close to users
 */
// Cloudflare Worker with D1
export default {
    async fetch(request: Request, env: Env): Promise<Response> {
        const orderId = new URL(request.url).searchParams.get('id');
        
        // D1 query - runs at edge, ultra-low latency
        const order = await env.DB.prepare(
            'SELECT * FROM orders WHERE id = ?'
        ).bind(orderId).first();
        
        return Response.json(order);
    }
};

Serverless Database Selection

For new serverless projects, consider serverless-native databases (Neon, PlanetScale, Supabase) that handle connection pooling transparently. For existing RDS databases, use RDS Proxy. Avoid connecting directly from Lambda to traditional RDS without a proxy—you'll hit connection limits under load.

Event-Driven Architecture and Database Interaction

Event-driven architecture (EDA) structures applications around the production, detection, and reaction to events. This paradigm has profound implications for database interaction patterns, particularly in distributed systems.

Core Concepts

Event: A significant occurrence in the system (OrderCreated, PaymentReceived, InventoryUpdated)
Event Producer: Service that publishes events when state changes
Event Consumer: Service that reacts to events
Event Broker: Infrastructure routing events (Kafka, RabbitMQ, AWS EventBridge)

Event Sourcing Pattern

Instead of storing current state, store the sequence of events that led to current state:

Traditional: orders table has current order state
Event Sourced: order_events table has all state changes

Events for Order #123:
1. OrderCreated { items: [...], total: 99.00 }
2. PaymentReceived { amount: 99.00 }
3. ItemShipped { trackingNumber: "1Z999..." }
4. ItemDelivered { timestamp: "2024-01-15T10:30:00Z" }

Current state reconstructed by replaying events

CQRS (Command Query Responsibility Segregation)

Separate read and write models:

Command side: Handles writes; validates and persists events
Query side: Optimized for reads; separate denormalized views
Events synchronize query side from command side

Converting Mermaid diagram...

Change Data Capture (CDC)

Capture database changes as events without application modification:

Debezium: Open-source CDC platform reading database transaction logs
AWS DMS: Managed CDC for database migration and replication
Oracle GoldenGate: Enterprise CDC solution

CDC enables:

Streaming database changes to Kafka
Keeping search indexes in sync (Elasticsearch)
Populating data warehouses in real-time
Cross-service data synchronization without coupling

Database ---> CDC (Debezium) ---> Kafka ---> Elasticsearch
            ---> Analytics DB
            ---> Cache Invalidation

EDA Database Interaction Patterns

•Transactional Outbox: Write event to database table atomically with business data; separate process publishes to message broker
•Event Store as Primary Database: Events are the source of truth; derived views rebuilt from events
•Materialized Views from Events: Query databases populated by consuming event streams
•Saga Orchestration: Saga coordinator queries aggregate state to determine next step
•Event-Carried State Transfer: Events include full state, reducing need for queries

Eventual Consistency Trade-offs

Event-driven systems are eventually consistent. After an order is created, it may take milliseconds to seconds before the read model reflects the change. User experiences must account for this—showing 'order submitted, confirming...' rather than immediately querying for order details.

Polyglot Persistence: The Right Database for Each Job

Modern applications often use multiple database technologies, each selected for specific strengths. This polyglot persistence approach treats databases as specialized tools rather than one-size-fits-all solutions.

Common Database Technology Combinations

RDBMS (PostgreSQL): Core transactional data, complex queries, ACID guarantees
Document Store (MongoDB): Flexible schemas, nested data, rapid iteration
Cache (Redis): Session storage, rate limiting, hot data caching
Search (Elasticsearch): Full-text search, faceted filtering, log analysis
Graph (Neo4j): Relationship-heavy queries, recommendations, fraud detection
Time Series (TimescaleDB, InfluxDB): Metrics, IoT data, monitoring
Analytics (ClickHouse, BigQuery): OLAP queries, aggregations, dashboards

Database Selection by Use Case
Use Case	Primary Database	Why This Choice	Example Query Pattern
Order Management	PostgreSQL	ACID transactions, complex joins, referential integrity	JOINs across orders, items, customers
Product Catalog	MongoDB	Flexible attributes per product category	Nested product variants and specifications
Session Store	Redis	Sub-millisecond reads, built-in expiration	GET/SET with TTL for session tokens
Product Search	Elasticsearch	Full-text search, faceted navigation	Search 'blue running shoes' with filters
Recommendations	Neo4j	Traverse purchase relationships	'Customers who bought X also bought Y'
Metrics/Monitoring	TimescaleDB	Time-based aggregation, retention policies	AVG(response_time) per hour for last week
Business Analytics	BigQuery	Petabyte-scale analytics, SQL interface	Revenue by region by month for 5 years

Synchronization Challenges

With multiple databases, keeping data synchronized is critical:

Dual Writes (Anti-Pattern): Application writes to both RDBMS and Elasticsearch. If one fails, data diverges. Avoid this.

CDC-Based Sync (Recommended): Primary database writes captured and streamed to secondary stores.

PostgreSQL --CDC--> Kafka ---> Elasticsearch Consumer
                           ---> Redis Cache Invalidator

Application-Level Events: After committing to primary, publish event for other systems to consume.

@Transactional
public void updateProduct(Product product) {
    productRepository.save(product);  // PostgreSQL
    eventPublisher.publish(new ProductUpdatedEvent(product));  // Triggers ES update
}

Read-Through Cache: Application reads from cache; on miss, queries primary and populates cache.

Start Simple, Add Databases When Needed

Don't adopt polyglot persistence prematurely. Start with a single database (PostgreSQL handles most needs). Add specialized databases only when you have clear requirements that justify the operational complexity. Each database technology is another system to operate, backup, monitor, and secure.

Choosing the Right Architecture

With multiple architectural patterns available, how do you choose? There's no universally correct answer—the right architecture depends on your specific context.

Decision Framework

Team Size and Skills: Small team → simpler architecture. Complex microservices require DevOps maturity.
Scale Requirements: Few thousand users → monolith is fine. Millions of users → consider distributed.
Deployment Velocity: Deploy daily → need independent deployability. Quarterly releases → monolith works.
Domain Complexity: Simple CRUD → three-tier. Complex business domains → consider bounded contexts.
Regulatory Requirements: Strong consistency mandates → be careful with eventual consistency.

Architecture Selection Guide
Scenario	Recommended Architecture	Database Pattern	Rationale
Startup MVP, 3-person team	Three-tier monolith	Single PostgreSQL	Speed to market; simplicity
Enterprise internal app, 50 users	Three-tier with app server	SQL Server with connection pooling	Stable, proven, maintainable
E-commerce, 10K daily orders	Three-tier, maybe extract services	PostgreSQL + Redis cache	Mostly monolith with caching
SaaS platform, multi-tenant	Microservices (gradual)	Database per service + tenant isolation	Team scaling; independent deployment
IoT platform, millions of devices	Event-driven + serverless	Time-series DB + object storage	Ingestion scale; event processing
Financial trading system	Custom low-latency	In-memory + persistent log	Every microsecond matters

Signs You Need Simpler

•Team is small and cross-functional
•Traffic is predictable and moderate
•Domain is well-understood
•Strong consistency is required
•Operational simplicity is prioritized

Signs You Need More Complex

•Multiple teams need independent deployment
•Traffic varies dramatically (10x-100x swings)
•Different components have different scaling needs
•Global distribution is required
•Event processing is core to the business

The Modular Monolith Middle Ground

You don't have to choose between monolith and microservices. A modular monolith maintains clear boundaries between components while deploying as a single unit. This gives you the ability to extract services later while keeping operational simplicity now. Many successful companies (Shopify, Basecamp) use this approach.

Summary: Modern Architecture Landscape

We've explored the contemporary landscape of database access architectures—patterns that have evolved beyond traditional client-server models to meet modern demands. Let's consolidate the essential concepts:

Key Takeaways

•Microservices architecture enforces database-per-service encapsulation, requiring API-based data access and saga patterns for distributed transactions
•API gateways serve as the modern front door, handling routing, authentication, rate limiting, and optionally aggregating data from multiple backend services
•Cloud-native patterns leverage managed services with infrastructure-level connection pooling (RDS Proxy), IAM authentication, and private networking
•Serverless computing creates unique challenges for database connections; solutions include connection proxies, serverless-native databases, and HTTP-based data APIs
•Event-driven architecture enables loose coupling through event streaming, event sourcing, CQRS, and change data capture patterns
•Polyglot persistence uses specialized databases for specific use cases, synchronized via CDC or application events—but adds operational complexity
•Architecture selection depends on context: team size, scale requirements, deployment velocity, and domain complexity should guide decisions
•Start simple and evolve: A modular monolith can be extracted into services when genuinely needed; premature distribution increases complexity

Module Complete:

This concludes our exploration of Client-Server Architecture. We've journeyed from the foundational two-tier model through three-tier enterprise patterns, into the depths of application servers and connection pooling, and finally to modern distributed architectures.

These architectural patterns form the infrastructure context in which database systems operate. Understanding them enables you to make informed decisions about database deployment, access patterns, and scaling strategies—skills essential for any database professional working in enterprise or cloud environments.

Module Complete

You now understand the complete spectrum of client-server architectures for database systems—from traditional two-tier and three-tier patterns to modern microservices, cloud-native, serverless, and event-driven approaches. This architectural foundation enables you to evaluate, design, and implement database access patterns appropriate for any scale and deployment model.

Modern Architectures: Beyond Traditional Client-Server

The Architectural Evolution Continues

The Driving Forces of Change

Cloud Computing: Infrastructure as code, pay-per-use, global distribution
Microservices Movement: Decomposing monoliths into independently deployable services
DevOps Culture: Development and operations merge; deployment automation becomes critical
API Economy: Services expose capabilities via APIs; integration everywhere
Data Growth: Exponential data volumes require new storage and processing paradigms

What You Will Master

Microservices Architecture and Database Patterns

The Database-Per-Service Pattern

A fundamental principle of microservices is that each service owns its data exclusively:

Encapsulation: Each service has its own database (or schema); no direct database sharing
Loose coupling: Services communicate via APIs, not shared tables
Independent scaling: Each database can scale according to its service's needs
Technology freedom: Different services can use different database technologies (PostgreSQL, MongoDB, Redis, etc.)

What This Means in Practice

If Order Service needs customer information:

DON'T: Query Customer database directly
DO: Call Customer Service API

This creates network overhead but ensures services can evolve independently.

Converting Mermaid diagram...

Challenges of Microservices Database Patterns

Data Consistency: Without shared transactions, maintaining consistency across services requires careful design (saga pattern, eventual consistency)
Query Complexity: Joins across services require API composition or data duplication
Operational Overhead: Many databases to manage, backup, monitor
Connection Proliferation: Each service needs connection pools; total connections multiply

Distributed Transactions vs. Saga Pattern

Traditional distributed transactions (XA) don't scale well in microservices. The Saga Pattern provides an alternative:

Break distributed operation into local transactions
Each service commits its local transaction
If later step fails, execute compensating transactions to undo earlier steps

Order Saga:
1. Order Service: Create order (PENDING)
2. Payment Service: Reserve funds
3. Inventory Service: Reserve stock
4. Order Service: Confirm order (CONFIRMED)

If step 3 fails:
4c. Payment Service: Release reserved funds (compensating)
5c. Order Service: Cancel order (compensating)

Distributed Systems Are Hard

API Gateway Pattern: The Modern Front Door

API Gateway Responsibilities

Request Routing: Direct requests to appropriate backend services based on path, headers, or content
Authentication/Authorization: Validate tokens, enforce access policies before requests reach services
Rate Limiting: Protect backend services from traffic spikes and abuse
Request/Response Transformation: Adapt protocols, aggregate responses, translate formats
Caching: Cache responses for repeated queries
Observability: Centralized logging, tracing, metrics collection

Popular API Gateway Solutions

API Gateway Technology Comparison
Gateway	Type	Strengths	Database Interaction Pattern
Kong	Open Source/Enterprise	Plugin ecosystem, Lua extensibility	Routes to services; no direct DB access
AWS API Gateway	Cloud Managed	Deep AWS integration, serverless-ready	Can trigger Lambda for DB access
Azure API Management	Cloud Managed	Enterprise features, policy engine	Routes to Azure Functions/App Services
Apigee	Enterprise (Google)	Analytics, monetization	API proxying to backend services
Traefik	Cloud-native	Kubernetes-native, auto-discovery	Ingress controller routing to services
nginx/envoy	Reverse Proxy	Performance, control	L7 routing to application tier

Backend for Frontend (BFF) Pattern

A variation where separate gateways serve different client types:

Web BFF: Optimized for browser clients with session handling
Mobile BFF: Optimized for mobile with battery-conscious patterns
Partner BFF: Exposes subset of APIs for external integrators

Each BFF can aggregate data from multiple microservices, reducing client round-trips:

// Mobile BFF: Single endpoint returning composed data
GET /api/mobile/v1/dashboard

// Internally fans out to:
// - Customer Service: Get user profile
// - Order Service: Get recent orders
// - Notification Service: Get unread count
// Returns aggregated response optimized for mobile

GraphQL as API Gateway

GraphQL can function as a sophisticated API gateway, federating data from multiple services:

# Client requests exactly what they need
query {
  order(id: "123") {
    id
    status
    customer {       # Resolved from Customer Service
      name
      email
    }
    items {
      product {      # Resolved from Inventory Service
        name
        inStock
      }
      quantity
    }
  }
}

Gateway Is Not the Database Access Layer

Cloud-Native Database Patterns

Cloud-native architecture embraces ephemeral infrastructure, automated scaling, and managed services. This fundamentally changes how applications interact with databases.

Managed Database Services

Cloud providers offer databases as managed services:

Amazon RDS / Aurora: Managed PostgreSQL, MySQL, SQL Server
Azure SQL Database: Managed SQL Server with serverless options
Google Cloud SQL: Managed PostgreSQL, MySQL, SQL Server
PlanetScale: Managed MySQL with branching
Neon: Managed PostgreSQL with serverless scaling

Benefits of Managed Databases

Automated backups, patching, failover
Push-button scaling (vertical and read replicas)
Built-in monitoring and alerting
High availability configurations included
Reduced operational burden

Cloud-Native Connection Patterns

Cloud environments introduce unique connection considerations:

Cloud Database Connection Patterns

•IAM Authentication: Use cloud identity instead of passwords; tokens rotate automatically (RDS IAM, Cloud SQL IAM)
•Private Networking: Database on private subnet; accessed via VPC peering or private endpoints—never public internet
•Connection Proxy: Cloud-provided proxies (RDS Proxy, Cloud SQL Auth Proxy) handle authentication and pooling
•Secrets Management: Database credentials stored in secrets managers (AWS Secrets Manager, HashiCorp Vault); rotated automatically
•TLS Everywhere: Encrypted connections mandatory; certificates managed by cloud provider
•Regional Replicas: Read replicas in multiple regions for global read performance and disaster recovery

CloudNativeConfig.java
AWS RDS Config
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
// Cloud-Native Database Configuration Examples
 
@Configuration
public class CloudNativeDatabaseConfig {
    
    /**
     * Configuration using AWS RDS Proxy
     * - Handles connection pooling at infrastructure level
     * - Supports IAM authentication
     * - Automatic failover handling
     */
    @Bean
    @Profile("aws")
    public DataSource awsRdsProxyDataSource() {
        HikariConfig config = new HikariConfig();
        
        // Connect to RDS Proxy, not directly to RDS
        config.setJdbcUrl(
            "jdbc:postgresql://my-rds-proxy.proxy-xxxxx.us-east-1.rds.amazonaws.com:5432/appdb"
        );
        
        // IAM Authentication: token-based, auto-rotating
        if (useIamAuth) {
            config.setUsername("iam_user");
            // Password is generated IAM token, not static credential
            config.setPassword(generateRdsAuthToken());
            
            // Token expires after 15 minutes; must handle rotation
            config.setMaxLifetime(900_000);  // 15 minutes
        } else {
            // Credentials from Secrets Manager
            DatabaseSecret secret = secretsManager.getSecret("prod/rds/credentials");
            config.setUsername(secret.getUsername());
            config.setPassword(secret.getPassword());
        }
        
        // Smaller pool - RDS Proxy handles pooling at infrastructure
        config.setMaximumPoolSize(10);
        
        // SSL required for cloud connections
        config.addDataSourceProperty("ssl", "true");
        config.addDataSourceProperty("sslmode", "verify-full");
        
        return new HikariDataSource(config);
    }
    
    /**
     * Generate RDS IAM authentication token
     * Token is short-lived; connection must be established within ~15 min
     */
    private String generateRdsAuthToken() {
        RdsUtilities rdsUtilities = RdsUtilities.builder()
            .region(Region.US_EAST_1)
            .build();
        
        return rdsUtilities.generateAuthenticationToken(
            GenerateAuthenticationTokenRequest.builder()
                .hostname("my-rds-instance.xxxxx.us-east-1.rds.amazonaws.com")
                .port(5432)
                .username("iam_user")
                .build()
        );
    }
    
    /**
     * Configuration for serverless database (Neon, PlanetScale serverless)
     * These scale to zero and auto-scale up
     */
    @Bean
    @Profile("serverless-db")
    public DataSource serverlessDataSource() {
        HikariConfig config = new HikariConfig();
        
        // Serverless databases often use HTTP/WebSocket protocols
        // or standard connections with auto-scaling backend
        config.setJdbcUrl(System.getenv("DATABASE_URL"));
        
        // Smaller pools - serverless DB handles scaling
        config.setMaximumPoolSize(5);
        
        // Faster connection turnover for scale-to-zero databases
        config.setMaxLifetime(300_000);  // 5 minutes
        config.setIdleTimeout(60_000);   // 1 minute
        
        return new HikariDataSource(config);
    }
}

RDS Proxy: The Cloud Connection Pool

Serverless Architecture and Database Challenges

The Connection Problem

Traditional connection pooling assumes long-running processes:

Pool initializes once, reuses connections
Connections amortize creation cost over many requests

Serverless functions break these assumptions:

Functions may be cold (no existing connections)
Multiple function instances run in parallel
Each instance might create its own connections
Functions terminate, connections dangle or close

Scenario: Lambda function receives 1,000 concurrent requests:

Traditional: 1 pool with 20 connections serves all requests
Serverless (naive): 1,000 function instances each create 1 connection = 1,000 database connections

This quickly overwhelms database connection limits.

Serverless Database Access Strategies
Strategy	How It Works	Pros	Cons
RDS Proxy / Cloud SQL Auth Proxy	External proxy pools connections; functions connect to proxy	Transparent to application; handles pooling	Additional cost; slight latency
Serverless-Native Databases	Neon, PlanetScale, Aurora Serverless v2—designed for serverless	Scale to zero; built-in pooling	Vendor lock-in; learning curve
HTTP/REST Data APIs	Database exposes HTTP API (Aurora Data API)	No persistent connections; simple	Limited features; higher latency
Connection Reuse	Reuse connection across warm invocations	Simple; no external dependencies	Cold starts still create connections
Edge Databases	Database on edge (D1, Turso)	Ultra-low latency; geo-distributed	SQLite-based; limited scale-up

ServerlessDbAccess.ts
AWS Lambda (TypeScript)
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
// Serverless Database Access Patterns
 
import { Client } from 'pg';
import { RDSDataClient, ExecuteStatementCommand } from '@aws-sdk/client-rds-data';
 
/**
 * Pattern 1: Connection Reuse (works with RDS Proxy)
 * Connection created outside handler persists across warm invocations
 */
let connection: Client | null = null;
 
export const withConnectionReuse = async (event: any) => {
    // Reuse existing connection if warm invocation
    if (!connection) {
        connection = new Client({
            host: process.env.RDS_PROXY_ENDPOINT,
            database: 'appdb',
            user: process.env.DB_USER,
            password: process.env.DB_PASSWORD,
            ssl: { rejectUnauthorized: false },
        });
        await connection.connect();
    }
    
    try {
        const result = await connection.query(
            'SELECT * FROM orders WHERE id = $1',
            [event.orderId]
        );
        
        return {
            statusCode: 200,
            body: JSON.stringify(result.rows[0]),
        };
    } catch (error) {
        // Connection might be stale; reset for next invocation
        connection = null;
        throw error;
    }
};
 
/**
 * Pattern 2: Aurora Data API (HTTP-based, no connections)
 * Best for sporadic traffic and simplicity
 */
const rdsData = new RDSDataClient({ region: 'us-east-1' });
 
export const withDataApi = async (event: any) => {
    const command = new ExecuteStatementCommand({
        resourceArn: process.env.AURORA_CLUSTER_ARN,
        secretArn: process.env.AURORA_SECRET_ARN,
        database: 'appdb',
        sql: 'SELECT * FROM orders WHERE id = :orderId',
        parameters: [
            { name: 'orderId', value: { longValue: event.orderId } },
        ],
    });
    
    const result = await rdsData.send(command);
    
    // Data API returns structured response
    const order = mapDataApiResponseToOrder(result.records);
    
    return {
        statusCode: 200,
        body: JSON.stringify(order),
    };
};
 
/**
 * Pattern 3: Serverless-Native Database (Neon, PlanetScale)
 * These databases are designed for serverless workloads
 */
import { neon } from '@neondatabase/serverless';
 
export const withNeonServerless = async (event: any) => {
    // Neon uses HTTP-based driver optimized for serverless
    const sql = neon(process.env.NEON_DATABASE_URL!);
    
    // No connection management needed
    const order = await sql`
        SELECT * FROM orders WHERE id = ${event.orderId}
    `;
    
    return {
        statusCode: 200,
        body: JSON.stringify(order),
    };
};
 
/**
 * Pattern 4: Edge Database (Cloudflare D1, Turso)
 * SQLite-based, runs close to users
 */
// Cloudflare Worker with D1
export default {
    async fetch(request: Request, env: Env): Promise<Response> {
        const orderId = new URL(request.url).searchParams.get('id');
        
        // D1 query - runs at edge, ultra-low latency
        const order = await env.DB.prepare(
            'SELECT * FROM orders WHERE id = ?'
        ).bind(orderId).first();
        
        return Response.json(order);
    }
};

Serverless Database Selection

Event-Driven Architecture and Database Interaction

Core Concepts

Event: A significant occurrence in the system (OrderCreated, PaymentReceived, InventoryUpdated)
Event Producer: Service that publishes events when state changes
Event Consumer: Service that reacts to events
Event Broker: Infrastructure routing events (Kafka, RabbitMQ, AWS EventBridge)

Event Sourcing Pattern

Instead of storing current state, store the sequence of events that led to current state:

Traditional: orders table has current order state
Event Sourced: order_events table has all state changes

Events for Order #123:
1. OrderCreated { items: [...], total: 99.00 }
2. PaymentReceived { amount: 99.00 }
3. ItemShipped { trackingNumber: "1Z999..." }
4. ItemDelivered { timestamp: "2024-01-15T10:30:00Z" }

Current state reconstructed by replaying events

CQRS (Command Query Responsibility Segregation)

Separate read and write models:

Command side: Handles writes; validates and persists events
Query side: Optimized for reads; separate denormalized views
Events synchronize query side from command side

Converting Mermaid diagram...

Change Data Capture (CDC)

Capture database changes as events without application modification:

Debezium: Open-source CDC platform reading database transaction logs
AWS DMS: Managed CDC for database migration and replication
Oracle GoldenGate: Enterprise CDC solution

CDC enables:

Streaming database changes to Kafka
Keeping search indexes in sync (Elasticsearch)
Populating data warehouses in real-time
Cross-service data synchronization without coupling

Database ---> CDC (Debezium) ---> Kafka ---> Elasticsearch
            ---> Analytics DB
            ---> Cache Invalidation

EDA Database Interaction Patterns

•Transactional Outbox: Write event to database table atomically with business data; separate process publishes to message broker
•Event Store as Primary Database: Events are the source of truth; derived views rebuilt from events
•Materialized Views from Events: Query databases populated by consuming event streams
•Saga Orchestration: Saga coordinator queries aggregate state to determine next step
•Event-Carried State Transfer: Events include full state, reducing need for queries

Eventual Consistency Trade-offs

Polyglot Persistence: The Right Database for Each Job

Common Database Technology Combinations

RDBMS (PostgreSQL): Core transactional data, complex queries, ACID guarantees
Document Store (MongoDB): Flexible schemas, nested data, rapid iteration
Cache (Redis): Session storage, rate limiting, hot data caching
Search (Elasticsearch): Full-text search, faceted filtering, log analysis
Graph (Neo4j): Relationship-heavy queries, recommendations, fraud detection
Time Series (TimescaleDB, InfluxDB): Metrics, IoT data, monitoring
Analytics (ClickHouse, BigQuery): OLAP queries, aggregations, dashboards

Database Selection by Use Case
Use Case	Primary Database	Why This Choice	Example Query Pattern
Order Management	PostgreSQL	ACID transactions, complex joins, referential integrity	JOINs across orders, items, customers
Product Catalog	MongoDB	Flexible attributes per product category	Nested product variants and specifications
Session Store	Redis	Sub-millisecond reads, built-in expiration	GET/SET with TTL for session tokens
Product Search	Elasticsearch	Full-text search, faceted navigation	Search 'blue running shoes' with filters
Recommendations	Neo4j	Traverse purchase relationships	'Customers who bought X also bought Y'
Metrics/Monitoring	TimescaleDB	Time-based aggregation, retention policies	AVG(response_time) per hour for last week
Business Analytics	BigQuery	Petabyte-scale analytics, SQL interface	Revenue by region by month for 5 years

Synchronization Challenges

With multiple databases, keeping data synchronized is critical:

Dual Writes (Anti-Pattern): Application writes to both RDBMS and Elasticsearch. If one fails, data diverges. Avoid this.

CDC-Based Sync (Recommended): Primary database writes captured and streamed to secondary stores.

PostgreSQL --CDC--> Kafka ---> Elasticsearch Consumer
                           ---> Redis Cache Invalidator

Application-Level Events: After committing to primary, publish event for other systems to consume.

@Transactional
public void updateProduct(Product product) {
    productRepository.save(product);  // PostgreSQL
    eventPublisher.publish(new ProductUpdatedEvent(product));  // Triggers ES update
}

Read-Through Cache: Application reads from cache; on miss, queries primary and populates cache.

Start Simple, Add Databases When Needed

Choosing the Right Architecture

With multiple architectural patterns available, how do you choose? There's no universally correct answer—the right architecture depends on your specific context.

Decision Framework

Team Size and Skills: Small team → simpler architecture. Complex microservices require DevOps maturity.
Scale Requirements: Few thousand users → monolith is fine. Millions of users → consider distributed.
Deployment Velocity: Deploy daily → need independent deployability. Quarterly releases → monolith works.
Domain Complexity: Simple CRUD → three-tier. Complex business domains → consider bounded contexts.
Regulatory Requirements: Strong consistency mandates → be careful with eventual consistency.

Architecture Selection Guide
Scenario	Recommended Architecture	Database Pattern	Rationale
Startup MVP, 3-person team	Three-tier monolith	Single PostgreSQL	Speed to market; simplicity
Enterprise internal app, 50 users	Three-tier with app server	SQL Server with connection pooling	Stable, proven, maintainable
E-commerce, 10K daily orders	Three-tier, maybe extract services	PostgreSQL + Redis cache	Mostly monolith with caching
SaaS platform, multi-tenant	Microservices (gradual)	Database per service + tenant isolation	Team scaling; independent deployment
IoT platform, millions of devices	Event-driven + serverless	Time-series DB + object storage	Ingestion scale; event processing
Financial trading system	Custom low-latency	In-memory + persistent log	Every microsecond matters

Signs You Need Simpler

•Team is small and cross-functional
•Traffic is predictable and moderate
•Domain is well-understood
•Strong consistency is required
•Operational simplicity is prioritized

Signs You Need More Complex

•Multiple teams need independent deployment
•Traffic varies dramatically (10x-100x swings)
•Different components have different scaling needs
•Global distribution is required
•Event processing is core to the business

The Modular Monolith Middle Ground

Summary: Modern Architecture Landscape

Key Takeaways

•Microservices architecture enforces database-per-service encapsulation, requiring API-based data access and saga patterns for distributed transactions
•API gateways serve as the modern front door, handling routing, authentication, rate limiting, and optionally aggregating data from multiple backend services
•Cloud-native patterns leverage managed services with infrastructure-level connection pooling (RDS Proxy), IAM authentication, and private networking
•Serverless computing creates unique challenges for database connections; solutions include connection proxies, serverless-native databases, and HTTP-based data APIs
•Event-driven architecture enables loose coupling through event streaming, event sourcing, CQRS, and change data capture patterns
•Polyglot persistence uses specialized databases for specific use cases, synchronized via CDC or application events—but adds operational complexity
•Architecture selection depends on context: team size, scale requirements, deployment velocity, and domain complexity should guide decisions
•Start simple and evolve: A modular monolith can be extracted into services when genuinely needed; premature distribution increases complexity

Module Complete:

Module Complete