← back to projects
INTERNAL2025
Monolith to Microservices Migration
At Rampwin, the monolith had become the org-level risk: deployment coupling meant any release could affect unrelated domains, a single bad query could degrade the entire platform, and a service failure could cascade everywhere. I led the migration. Started with event storming to map domain boundaries, no code changes until the boundaries were agreed and service contracts were defined. Used strangler fig for incremental extraction with feature-flag traffic routing. Built the observability layer in parallel so failure modes were tracked from day one, not discovered reactively. Result: MTTR dropped 28%, deployment frequency increased across teams, and cross-domain incidents became structurally impossible.
$ Architecture
- →Event storming workshop output: 6 bounded contexts identified and agreed before any code was touched, domain boundaries as first-class design artifacts
- →Strangler fig extraction: new service traffic routed via feature flags at the Nginx layer; monolith kept live and functional until consumer migration was verified complete
- →Kafka event bus as the inter-service communication fabric, async, decoupled, replay-capable; services produce and consume domain events without direct coupling
- →Distributed sagas for cross-service transactions (checkout, order lifecycle), replacing monolith ACID guarantees with explicit eventual consistency and compensating actions
- →Per-service MongoDB collections with no shared schema, data ownership enforced at the persistence layer, not just the API layer
- →Istio service mesh for mTLS between services, distributed tracing via Jaeger, and controlled traffic shaping during phased cutover
$ Tech Stack
JavaSpring BootMongoDBKafkaDockerKubernetesIstio
$ Outcomes
→MTTR reduced 28%, failures in one bounded context are now structurally contained and cannot cascade
→Independent deployment pipelines per service: teams release without coordination overhead or shared deployment windows
→API contract testing (Pact) enforced in CI, breaking changes caught before staging, on every commit
→Distributed saga orchestration for checkout and order workflows with full compensating transaction support and idempotent retry
→Per-service observability from day one: structured logs, distributed traces, and Prometheus metrics built into the service template
→MongoDB performance optimization under high-write load: compound index design, write concern tuning, and read replica routing