Migrating Legacy Monoliths to Event-Driven Microservices: A Strangler Fig Approach

The Problem: Tight Coupling

The client's system handled 500k daily transactions. The core logic was embedded in a single `.war` file deployed on legacy Tomcat servers. A change in the "User Profile" module often broke the "Payments" module due to shared database tables and synchronous in-memory calls.

The Solution: Event Interception

We didn't start by rewriting code. We started by intercepting data.

1. CDC (Change Data Capture): We implemented Debezium to listen to the legacy Oracle database logs. Every `INSERT` or `UPDATE` was streamed to a Kafka topic.
2. Shadow Microservices: We built new Go-based services that consumed these Kafka events. They built their own read-optimized databases (PostgreSQL).
3. The Switch: Once the shadow services were verified to be 100% accurate against the monolith, we flipped the API Gateway (Kong) to route read traffic to the new services.

func (c *Consumer) ConsumeClaim(msg *sarama.ConsumerMessage) {
    var event TransactionEvent
    json.Unmarshal(msg.Value, &event)
    
    // Process in isolated context
    if event.Type == "PAYMENT_INITIATED" {
        go c.FraudDetector.Analyze(event)
    }
}

Results

• Zero Downtime: The migration happened endpoint by endpoint.
• Scalability: The new Payment service can now scale independently during Black Friday spikes.
• Safety: If a new service failed, we simply routed traffic back to the monolith.