Database-per-Service: Designing Resilient Microservices Databases

The database-per-service pattern is an architectural design where each microservice owns its private datastore, preventing external services from accessing the database directly. To implement this pattern, services must communicate exclusively via REST/gRPC API contracts or event-driven message brokers, handling data consistency across boundaries using asynchronous replication or the Saga transaction orchestration pattern. Direct SQL joins across schemas are strictly prohibited.

For startup founders and software directors, failing to isolate databases is the fastest way to turn a microservices project into a "distributed monolith" that is slow, difficult to deploy, and fragile. Partnering with a specialist like a bhalli software architecture consultant ensures your service boundaries are designed with proper data isolation and API contracts from day one.

1. The Core Architecture of Database Isolation

In a traditional monolithic application, all modules query a single central database. If the Billing module needs user profiles, it performs an SQL JOIN on the users and billing_records tables. This is simple, fast, and maintains ACID transactions out of the box.

However, when scaling, this shared database becomes a massive bottleneck. A schema change in the User table can break the Billing code, requiring simultaneous redeployment of both systems. Furthermore, a heavy query load on the Billing service can drain the database connection pool, starving the User auth service and crashing the entire application.

By adopting the database-per-service pattern, we break these tight couplings:

• Private Data Stores: The User Service has its own User DB (e.g., PostgreSQL); the Billing Service has its own Billing DB (e.g., MongoDB).
• Strict Interface Boundaries: If Billing needs user data, it must call the User Service API: GET /v1/users/{id}.
• Independent Scaling: If User auth traffic spikes, you scale only the User Service container and User DB, leaving Billing completely unaffected.

2. Technical Implementation: BFF Aggregation & Event Processing

In a database-per-service architecture, frontends face a challenge: how do they display screen layouts that require data from multiple microservices? Instead of making five network calls from the browser (which ruins performance), we implement a BFF (Backend for Frontend) pattern inside a Next.js API route to aggregate the data on the server.

Below is a production-ready Next.js API endpoint illustrating BFF data aggregation, fetching details from independent User and Billing microservices concurrently:

// src/app/api/dashboard/bff/route.ts
import { NextRequest, NextResponse } from 'next/server';

const USER_SERVICE_API = process.env.USER_SERVICE_INTERNAL_URL || 'http://user-service.internal';
const BILLING_SERVICE_API = process.env.BILLING_SERVICE_INTERNAL_URL || 'http://billing-service.internal';

export async function GET(req: NextRequest) {
  const { searchParams } = new URL(req.url);
  const userId = searchParams.get('userId');

  if (!userId) {
    return NextResponse.json({ error: 'Missing userId parameter' }, { status: 400 });
  }

  try {
    // Fetch from independent microservices concurrently using Promise.all
    const [userRes, billingRes] = await Promise.all([
      fetch(`${USER_SERVICE_API}/v1/users/${userId}`, {
        headers: { 'Authorization': `Bearer ${process.env.INTERNAL_SERVICE_TOKEN}` }
      }),
      fetch(`${BILLING_SERVICE_API}/v1/billing/summary/${userId}`, {
        headers: { 'Authorization': `Bearer ${process.env.INTERNAL_SERVICE_TOKEN}` }
      })
    ]);

    // Handle service downgrades gracefully
    const userData = userRes.ok ? await userRes.json() : { name: 'Valued Customer', status: 'Active' };
    const billingData = billingRes.ok ? await billingRes.json() : { balance: 0, invoices: [] };

    // Aggregate and structure the payload for the frontend
    const aggregatedPayload = {
      user: {
        id: userId,
        name: userData.name,
        email: userData.email,
        status: userData.status,
      },
      billing: {
        outstandingBalance: billingData.balance,
        recentInvoices: billingData.invoices.slice(0, 5),
        hasOverdueBalance: billingData.balance > 0,
      },
      timestamp: new Date().toISOString(),
    };

    return NextResponse.json(aggregatedPayload, { status: 200 });
  } catch (error: any) {
    return NextResponse.json(
      { error: 'BFF Aggregation failed', message: error.message },
      { status: 502 }
    );
  }
}

This BFF pattern shields the frontend client from the complexity of your microservices network, providing a clean, single-endpoint interface.

Handling Transactions Across Services (The Saga Pattern)

Since we cannot run ACID transactions across distinct databases, we must handle multi-step actions (such as placing an order and charging a credit card) using event-driven architectures. Below is a code snippet demonstrating an event handler that processes payment approvals and updates database state asynchronously:

// src/app/api/events/payment-completed/route.ts
import { NextRequest, NextResponse } from 'next/server';

interface PaymentCompletedEvent {
  orderId: string;
  transactionId: string;
  amount: number;
  status: 'SUCCESS' | 'FAILED';
}

export async function POST(req: NextRequest) {
  try {
    const event: PaymentCompletedEvent = await req.json();

    // Verify event signature to ensure it came from our verified message broker
    const signature = req.headers.get('X-Broker-Signature');
    if (!signature || !verifyBrokerSignature(signature, event)) {
      return NextResponse.json({ error: 'Unauthorized event payload' }, { status: 401 });
    }

    if (event.status === 'SUCCESS') {
      // 1. Update Order Status in our local Order database
      await updateOrderStatus(event.orderId, 'PAID', event.transactionId);
      
      // 2. Trigger downstream event (e.g., Shipping allocation)
      await triggerShippingJob(event.orderId);
    } else {
      // Compensating transaction: Cancel order and release stock reservation
      await updateOrderStatus(event.orderId, 'PAYMENT_FAILED', null);
      await releaseStockReservation(event.orderId);
    }

    return NextResponse.json({ processed: true }, { status: 200 });
  } catch (err: any) {
    return NextResponse.json({ error: 'Event processing error', message: err.message }, { status: 500 });
  }
}

function verifyBrokerSignature(sig: string, body: any): boolean {
  // Production signature validation logic would go here
  return true;
}

async function updateOrderStatus(orderId: string, status: string, txId: string | null) {
  console.log(`[Order DB] Order ${orderId} status set to ${status}. Transaction: ${txId}`);
}

async function triggerShippingJob(orderId: string) {
  console.log(`[Shipping Service] Allocating courier for order ${orderId}`);
}

async function releaseStockReservation(orderId: string) {
  console.log(`[Inventory DB] Releasing reserved items for cancelled order ${orderId}`);
}

This compensating transaction pattern ensures eventual data consistency across your isolated microservices databases without locking resources.

3. Structural Comparison: Shared DB vs. Database-per-Service

Let's review how a shared database architecture compares with the database-per-service pattern across core infrastructure areas:

4. Real-World Trade-Offs and Budget Considerations

The database-per-service pattern is not a free lunch. It introduces substantial architectural complexity, especially regarding event replication, distributed monitoring, and eventual consistency.

When to Defer Database Isolation

If your startup is still in the pre-revenue validation phase with a small user base, the overhead of managing multiple database servers, event sync queues, and BFF aggregation endpoints will consume valuable time. In this phase, we recommend a Modular Monolith where code domains are cleanly separated into separate folders but share a single PostgreSQL database instance using separated schemas. This gives you a clear migration path to microservices later without incurring early infrastructure costs.

5. Contact BhalliSoft to Optimize Your Architecture

At Bhalli Software Solutions, we help scaling businesses design resilient database topologies. We implement high-performance BFF endpoints, configure event-driven message brokers, and audit existing monolith codebases for safe database decomposition.

Are you preparing to scale your database, or do you need a microservices migration feasibility review?

Book a Free Database Strategy Session with BhalliSoft to receive an architecture review, discuss event-driven patterns, or lay out a scaling plan for your SaaS. Let's design a database that scales.