Modular Monolith→Event-Driven Services
Duration Estimate
3–6 months or more
Migration Stages
6
Blocking Prerequisites
4
Confidence
StrongReadiness Checklist(4 blocking, 2 advisory)
Team at senior maturity level
This migration requires senior engineering maturity. The team should have hands-on experience with the relevant technologies and proven ability to execute complex system changes safely.
Guidance: Build team skills through learning modules before attempting this migration.
Production observability baseline established
Comprehensive metrics, logs, and traces must be in place before the migration starts. You need a clear baseline to detect regressions during and after each migration stage.
Guidance: Instrument key metrics (latency p99, error rate, throughput, resource utilization) on all affected components.
Rollback plan documented and tested
Rollback feasibility for this migration is 'rarely'. Rollback is difficult or impossible, validate the migration in a staging environment thoroughly before proceeding to production.
Guidance: Run a full dry-run in a staging environment that mirrors production load characteristics.
Data backup and validation strategy in place
This migration involves technology changes that affect data storage or access patterns. Ensure full backups are current and a data validation strategy is defined to confirm data integrity at each stage boundary.
Guidance: Perform a full backup before starting. Run data validation checksums after each stage.
'kafka' provisioned and validated in target environment
'kafka' must be available, configured, and load-tested in the target environment before the migration stage that introduces it.
Guidance: Deploy 'kafka' with production-equivalent configuration. Run a smoke test under representative load.
Migration trigger condition confirmed
Confirm that the actual trigger for this migration is present. Common triggers: Independent deployment needed: teams blocked by shared release coordination; Module scaling requirements diverge: one module needs 10x capacity, others do not; Fault isolation required: one module's failures must not cascade to the entire system.
Guidance: Validate the trigger with production metrics or benchmarks before committing to the migration timeline.
Migration Stages
Add a routing layer in front of the monolith. All traffic still hits the monolith. Instrument all inter-module calls so volume and latency are visible before splitting.
Key tasks
- ·Add a routing layer in front of the monolith. All traffic still hits the monolith. Instrument all inter-module calls so volume and latency are visible before splitting.
- ·Validate rollback capability at this stage boundary before proceeding.
Exit criteria
- ✓'Strangler Fig Preparation' validated in production with no regression in key metrics
Rollback: possible at this stage
Deploy message broker (Kafka or RabbitMQ). Establish topic naming conventions, serialization format (Avro/JSON), and consumer group conventions. Set up consumer lag monitoring before any service uses the broker.
Key tasks
- ·Deploy message broker (Kafka or RabbitMQ). Establish topic naming conventions, serialization format (Avro/JSON), and consumer group conventions. Set up consumer lag monitoring before any service uses the broker.
- ·Validate rollback capability at this stage boundary before proceeding.
Exit criteria
- ✓'Event Infrastructure Setup' validated in production with no regression in key metrics
Rollback: possible at this stage
The monolith begins emitting events for key domain events while still performing synchronous operations. New services consume events but do not yet replace monolith logic. Both paths coexist.
Key tasks
- ·The monolith begins emitting events for key domain events while still performing synchronous operations. New services consume events but do not yet replace monolith logic. Both paths coexist.
- ·Validate rollback capability at this stage boundary before proceeding.
Exit criteria
- ✓'Dual Write: Sync + Events' validated in production with no regression in key metrics
Rollback: possible at this stage
Extract the lowest-dependency module first (typically notifications, search indexing, or analytics). This service receives events and has no outbound calls to the monolith. Validate event schema, consumer lag behavior, and monitoring.
Key tasks
- ·Extract the lowest-dependency module first (typically notifications, search indexing, or analytics). This service receives events and has no outbound calls to the monolith. Validate event schema, consumer lag behavior, and monitoring.
- ·Validate rollback capability at this stage boundary before proceeding.
Exit criteria
- ✓'Leaf Service Extraction' validated in production with no regression in key metrics
Rollback: possible at this stage
Migrate extracted service to its own database. This is the highest-risk step. Requires dual-read period, data migration validation, and cutover coordination.
Key tasks
- ·Migrate extracted service to its own database. This is the highest-risk step. Requires dual-read period, data migration validation, and cutover coordination.
- ·No rollback available after this stage, confirm all exit criteria before proceeding.
Exit criteria
- ✓'Database Decomposition' validated in production with no regression in key metrics
[CRITICAL] Cross-service workflows that previously used database transactions now require Saga orchestration
Mitigation: Design idempotent event handlers; implement compensating transactions for every multi-step workflow; test failure injection in staging
[CRITICAL] Consumer lag silently accumulates: a lagging consumer is not a failed consumer
Mitigation: Alert on consumer lag rate-of-change, not absolute depth; implement dead letter queues with alerting
Rollback: not available after this stage
Repeat extraction for remaining modules in order of ascending dependency complexity. Each extraction validates event contracts, observability, and failure handling.
Key tasks
- ·Repeat extraction for remaining modules in order of ascending dependency complexity. Each extraction validates event contracts, observability, and failure handling.
- ·No rollback available after this stage, confirm all exit criteria before proceeding.
Exit criteria
- ✓'Iterative Core Extraction' validated in production with no regression in key metrics
Rollback: not available after this stage
Rollback Decision Points
After stage 4
Trigger: Any of the following in the 30 minutes after completing stage 4: p99 latency increases >50% from baseline, error rate exceeds 1%, or data consistency checks fail.
Procedure: Revert stage 4 changes. Rollback is rarely, follow the documented rollback procedure for 'modular-monolith-to-event-driven'. Engage senior engineering support.
Recovery: Hours to days, rollback is difficult for this migration
After stage 6
Trigger: Final validation: confirm all success criteria are met within 24 hours of migration completion. If any success criterion fails, trigger rollback or remediation.
Procedure: If success criteria are not met within 24 hours, escalate to the architecture team. Decide between full rollback, partial rollback, or targeted remediation based on scope.
Recovery: 24–72 hours for full assessment and remediation
Success Criteria
- ✓Target state 'Event-Driven Services' is stable in production for 72+ hours with no regressions.
- ✓p99 latency on all affected services is within acceptable range (≤110% of pre-migration baseline).
- ✓Error rate is at or below pre-migration baseline.
- ✓New components (kafka) are fully operational and monitored.
- ✓Data integrity verified: checksums or consistency checks confirm no data loss or corruption.
This migration playbook is derived from structured architecture knowledge. Duration estimates and risk levels are structural approximations based on documented migration complexity and operational risk, not measured execution data. Validate all stages against your specific system constraints before executing.