Breaking up the monolith without taking the platform down

The client is a B2B SaaS platform company whose product began, as most do, as a monolith. That was the right call for years. The codebase grew, the customer base grew, and the engineering organization grew around a shared release train. Every team shipped through the same deployment. The whole platform ran on infrastructure sized for its busiest day of the year.

Then the model stopped scaling with the business. A load spike in a hot module meant scaling the entire application. A defect in any team's code meant rolling back everyone's work. Debugging meant searching raw logs across servers, because no request could be followed as it crossed the system. The organization was growing faster than the architecture could absorb.

Kentro was engaged to take the platform apart without taking it down. The mandate was clear. Decompose the monolith into independently deployable services, migrate the platform to AWS, and build the delivery pipelines and observability needed to operate it. No big-bang cutover. No rewrite from scratch. The product had to stay in production the whole way through.

The monolith was not badly built. It was outgrown. The problems were structural, and they compounded as the team and the traffic grew.

• Coupled releases: Every change shipped as a full platform release. Unrelated teams blocked each other, and a rollback meant rolling back everything.
• Scaling everything for a hotspot: Load spikes in a hot module forced the client to scale the entire application, on infrastructure provisioned for the busiest day of the year.
• No visibility into failures: There was no tracing and no correlated view of a request as it crossed the system. Debugging meant searching raw logs server by server, and every failure looked like a platform failure.

The approach was extraction, not rewrite. Kentro mapped the monolith into bounded contexts and pulled services out using the strangler fig pattern while the platform stayed in production, then moved the estate onto AWS piece by piece. Pipelines and observability were built alongside the services, not bolted on afterwards.

• Domain-driven decomposition: The monolith was mapped into bounded contexts and services were extracted behind an API gateway using the strangler fig pattern. The monolith kept serving traffic while new services took over route by route.
• An AWS foundation on EKS: A multi-account landing zone with VPC segmentation, Amazon EKS for orchestration, and RDS and MSK as managed services. All of it provisioned through Terraform and applied through reviewed pull requests.
• Per-service CI/CD: GitHub Actions pipelines for each service cover automated tests, container builds and canary releases, with automated rollback on failed health checks.
• Events instead of shared tables: Direct cross-module database calls were replaced with events on Kafka, using the outbox pattern and a schema registry to keep producers and consumers compatible. The shared database was split so each service owns its data, with change data capture keeping the monolith and extracted services consistent during the transition.
• Observability built in: OpenTelemetry instrumentation across every service feeds distributed tracing, Prometheus metrics and Grafana dashboards, with structured logging and alerting tied to service-level objectives.

The migration itself is not the result. The result is how the platform operates day to day, and what the engineering organization stopped waiting for.

• Deployments became routine: Teams ship changes when they are ready instead of waiting for a scheduled platform release window. A rollback now affects a service, not the platform.
• Scaling follows demand: Busy services scale on their own. The platform no longer scales as a whole to serve its hottest module.
• Incidents are traceable: A failing request is traced to the owning service and team. Platform-wide investigations are no longer the default response to an alert.
• Teams own their services: Each team runs its services from code to production, with its own pipeline, dashboards and alerts.