Microservices to Monolith Migration: Strangler Fig

Answer-First: Consolidating fragmented microservices back into a modular monolith utilizes the Reverse Strangler Fig pattern with dual-writing and zero-downtime database schema mergers. Merging database schemas using logical schema separation (PostgreSQL schemas) preserves strict module autonomy while eliminating distributed transaction complexity.

Pillar Architecture Guide: This article is part of the Architecting 21-Service E-commerce with Golang & DDD series and Composable E-Commerce Migration guide. Please refer to the original article for an architectural overview of the architecture.

Prerequisite: Before reading this part, please review Part 5: Observability in Memory.

What You’ll Learn That AI Won’t Tell You:

• Database Consolidation Math: How to merge connection pools to optimize database RAM utilization.
• Transactional Outbox Implementations: The SQL schema design for safe event auditing during migrations.
• Canary Merging Safety: Running dual-writes for 14 days to audit state reconciliation before switching readers.

Breaking a monolith into multiple microservices is known as the Strangler Fig Pattern. Consolidating distributed microservices back into a central modular monolith system follows the opposite direction: the Reverse Strangler Fig Pattern.

Although merging application code is straightforward, the primary operational risks lie in database consolidation and organizational alignment. The flowchart below outlines the 4-stage lifecycle of microservice consolidation.

flowchart TD
    A[Legacy Microservice Network] -->|Phase 1: Dual-Write / CDC| B[("Old Microservice DB")]
    A -->|Phase 1: Dual-Write / CDC| C[("New Monolith Schema")]
    C -->|Phase 2: Asynchronous Backfill| D["Verify Parity & Reconciliation"]
    D -->|Phase 3: Switch Gateway Readers| E[Unified Modular Monolith]
    E -->|Phase 4: Decommission| F["Delete Old Microservice & DB"]

1. Conway’s Law: Organizational Preparation

Answer-first: Conway’s Law dictates that software architecture mirrors organizational communication. Merging microservices back into a modular monolith requires first restructuring isolated engineering pods into domain macro-teams sharing unified monorepo governance.

In 1968, Melvin Conway stated:

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Transitioning from microservices to a modular monolith fails if engineering teams remain isolated in silos without cross-domain communication.

Action Plan:

• Group small engineering pods into larger Domain Teams (Macro-teams).
• Establish clear code contribution rules on a shared repository (monorepo codebase) before merging code.

2. Reverse Strangler Fig Pattern & Routing Strategies

Answer-first: The Reverse Strangler Fig pattern safely migrates microservice logic into internal monolith packages using Anti-Corruption Layers (ACLs) and canary API Gateway routing, allowing gradual traffic migration without user disruption.

A. Strangler Fig vs Reverse Strangler Fig

Understanding the direction of migration ensures appropriate architectural trade-offs:

B. Implementation Steps

1. Create a New Module Inside the Monolith: Create a new package/module (e.g., PaymentModule) inside the modular monolith, enforcing bounded context boundaries (see Part 3).
2. Build an Anti-Corruption Layer (ACL): Build a translation layer so the new module communicates cleanly with existing domain modules without leaking legacy microservice schemas.
3. Gateway Canary Routing & Feature Flags: Use Envoy, NGINX, or OpenFeature toggles to route incoming traffic incrementally (5% → 25% → 100%) to the monolith module based on tenant ID or request headers.

For database routing details, refer to our Modular Monolith Architecture Guide.

3. Database Consolidation: CDC vs Application Dual-Writing

Answer-first: Database consolidation requires a 3-phase synchronization strategy: choice between application dual-writing or Change Data Capture (CDC) via Debezium and Kafka, 14-day zero-discrepancy reconciliation, and final zero-downtime read cutover.

Moving code carries low risk; making errors when consolidating data causes catastrophic data corruption.

A. CDC (Debezium + Kafka) vs Application-Level Dual-Writing

Selecting an appropriate database synchronization strategy requires balancing application code complexity against transaction log replication overhead. The comparison table below evaluates application-level dual-writing against log-based Change Data Capture (CDC) using Debezium and Kafka across key operational metrics.

B. The 4-Phase Schema Isolation Roadmap

To achieve database consolidation without downtime, engineering teams follow a strict 4-phase schema isolation roadmap:

1. Phase 1: Isolated DB Instances: Microservices operate on independent database servers.
2. Phase 2: CDC / Dual-Write Synchronization: Live transactional writes replicate from microservice DBs into co-located monolith database target schemas.
3. Phase 3: PostgreSQL Schema Namespaces (billing.*, inventory.*): Tables move into isolated schema namespaces on a single PostgreSQL instance, eliminating cross-database queries while retaining namespace boundaries.
4. Phase 4: Logical Module Schema Single-Pool: Application modules connect to a unified PostgreSQL connection pool while retaining strict schema namespace separation.

C. 14-Day Reconciliation Math

Daily automated checksum scripts compare live datasets across legacy microservice databases and target monolith schemas using mathematical reconciliation:

$$\text{Discrepancy Count} = \sum | \text{LegacyHash}(row) - \text{MonolithHash}(row) |$$

Read cutover proceeds only after Discrepancy Count strictly remains zero over 14 consecutive production days.

4. Transactional Outbox Worker Implementation

Answer-first: A Go transactional outbox worker processes domain events concurrently using non-blocking channels and context deadlines, guaranteeing eventual consistency across module schemas without distributed two-phase commits.

The Go code below demonstrates an asynchronous transactional outbox worker processing migration sync events without blocking HTTP handlers.

package main

import (
	"context"
	"fmt"
	"sync"
	"time"
)

type OutboxEvent struct {
	ID      int64
	Topic   string
	Payload string
	Status  string
}

type OutboxWorker struct {
	eventsChan chan OutboxEvent
}

func NewOutboxWorker() *OutboxWorker {
	return &OutboxWorker{
		eventsChan: make(chan OutboxEvent, 10),
	}
}

func (w *OutboxWorker) Run(ctx context.Context, wg *sync.WaitGroup) {
	defer wg.Done()
	ticker := time.NewTicker(50 * time.Millisecond)
	defer ticker.Stop()

	for {
		select {
		case <-ctx.Done():
			fmt.Println("Outbox worker shutting down gracefully...")
			return
		case event := <-w.eventsChan:
			fmt.Printf("[Outbox Dispatcher] Transmitted Event #%d (%s): %s\n", event.ID, event.Topic, event.Payload)
		case <-ticker.C:
			// Poll pending events cleanly without time.Sleep
		}
	}
}

func main() {
	worker := NewOutboxWorker()
	var wg sync.WaitGroup

	ctx, cancel := context.WithTimeout(context.Background(), 200*time.Millisecond)
	defer cancel()

	wg.Add(1)
	go worker.Run(ctx, &wg)

	worker.eventsChan <- OutboxEvent{
		ID:      101,
		Topic:   "OrderMigrated",
		Payload: `{"order_id": "ord_990", "status": "CONSOLIDATED"}`,
		Status:  "PENDING",
	}

	wg.Wait()
	fmt.Println("Outbox worker migration check complete!")
}

5. SQL Schema Consolidation & Emergency Rollback Protocols

Before merging application code, database schemas must be co-located under a unified database instance. The SQL script below creates separate PostgreSQL schema namespaces and defines a transactional outbox table with trigger-based event auditing.

-- Create distinct schemas inside the consolidated database
CREATE SCHEMA IF NOT EXISTS billing;
CREATE SCHEMA IF NOT EXISTS inventory;

-- Define billing payments table
CREATE TABLE billing.payments (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_id VARCHAR(50) NOT NULL,
    amount NUMERIC(12, 2) NOT NULL,
    status VARCHAR(20) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- Define transaction outbox table for audit logging
CREATE TABLE billing.outbox (
    id BIGSERIAL PRIMARY KEY,
    aggregate_type VARCHAR(50) NOT NULL,
    aggregate_id VARCHAR(50) NOT NULL,
    event_type VARCHAR(100) NOT NULL,
    payload JSONB NOT NULL,
    processed BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- Index for processing optimization
CREATE INDEX idx_outbox_unprocessed ON billing.outbox (id) WHERE processed = FALSE;

-- Trigger to log outbox events on new payments
CREATE OR REPLACE FUNCTION billing.queue_payment_event()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO billing.outbox (aggregate_type, aggregate_id, event_type, payload)
    VALUES ('Payment', NEW.id::text, 'PaymentProcessed', json_build_object(
        'order_id', NEW.order_id,
        'amount', NEW.amount,
        'status', NEW.status
    ));
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_payment_processed
    AFTER INSERT ON billing.payments
    FOR EACH ROW
    EXECUTE FUNCTION billing.queue_payment_event();

Emergency Zero-Downtime Rollback Protocol

If data divergence or latency spikes occur during read cutover, operations teams execute the zero-downtime rollback protocol:

1. Instant Route Switch (0 seconds): Revert the API Gateway feature flag or routing rule to send 100% of read traffic back to legacy microservice endpoints.
2. Reverse Synchronization Engine: Activate reverse CDC pipeline from the monolith schema back to the legacy microservice database to sync any delta writes created during the cutover window.
3. Audit Log Inspection: Query billing.outbox for unprocessed events to reconcile state discrepancies before re-attempting cutover.

Explore when to selectively extract high-volume modules in Part 7: Extraction Pattern.

Frequently Asked Questions (FAQ)

Navigation & Next Steps

• Previous Part: Part 5: Observability in Memory
• Next Part: Continue to Part 7: Extraction Pattern
• Related Guides: Modular Monolith Architecture and C10M High-Concurrency Architecture

Need guidance consolidating legacy microservices into a high-performance monolith? Get in touch or hire our software architecture team for a system audit.