Example for Software as a Service: Deconstructing the Monolith-to-Microservices Journey

Most teams do not migrate away from a monolith because they want to. They do it because they have to. Earlier in my career, I joined a project as we began migrating a large monolithic application to microservices. The need was obvious as the system had become fragile, and even minor changes regularly caused regressions elsewhere.

I maintained the legacy system while building parts of the new platform, which exposed the reality on both sides. The old system demanded constant stabilization, while the new one required rapid iteration just to stay functional. It was my first experience with microservices, and it was not smooth. There was a fair amount of firefighting, and progress meant constantly balancing stability against forward movement. That experience shaped how I think about system design. It taught me to be pragmatic, to respect the cost of change, and to approach migrations with a clear understanding of their operational impact.

A few years back microservice was the default solution for modern software development given the hype and usage by top tech firms. In a short while the reality became obvious and a lot of companies struggled with the operational complexity that comes with running a microservice architecture. Many successful SaaS platforms began as monolithic applications. As these platforms grew, the limitations of monoliths became apparent, often prompting the transition to microservices.

This article walks through a practical example of how a SaaS company might deconstruct a monolithic architecture into microservices, highlighting the motivations, challenges and technical strategies involved.

The Starting Point: A Monolithic SaaS Application

Imagine a monolithic SaaS platform called TaskFlow, a productivity tool used by teams to manage projects, tasks and collaboration. TaskFlow is a single deployable application with a unified codebase, shared database, tight coupling (different parts of the system are highly dependent on each other) between modules (user, billing, reporting, notifications, tasks) and a single deployment pipeline. 

In the initial phase of development, TaskFlow was developed in a short period of time with very fast iterations. It was simple to debug and easy to deploy with a low operation overhead. TaskFlow has been working fine for months with thousands of users. Recently the marketing team had a successful campaign, the platform’s user base has now doubled and is projected to reach a million plus users in a year. There are new feature requests from customers and a couple more still on the backlog. The IT team has been pushing several new features lately and they discovered the following issues:

• Slower deployments: Deployments take longer than usual for every new release. A small change in the billing module requires redeploying the entire system.
• Scaling inefficiencies: The team also noticed heavy usage for api’s related to that task and notification module during work hours. The team has auto-scaling enabled and with this increase in traffic, the entire application (not just the task and notification module) scales.
• Increased risk of regressions: The codebase is now fragile, small changes resulted in unintended side effects in other modules. Recently, an update to the task status logic to support a new “archived” state resulted in the reporting module showing incorrect counts and notifications stopped triggering for completed tasks.
• Slower feature development: As a result of tight coupling between the modules, introducing new features is tricky because you need to update several modules to get a feature out. New developers spend weeks to understand a large portion of the system before making changes.

Identifying the Need for Microservices

The decision to move to microservices is rarely sudden. It is driven by specific pressures: 

1. Scalability Needs: The task and notification modules require independent scaling. A spike in traffic during work hours does not necessarily mean the entire app has to scale.
2. Deployment: Frequent releases increase risk in monoliths. Also deploying a feature for a single module can be slow because you need to redeploy the entire system.
3. Domain Complexity: Business logic becomes harder to manage in a single codebase.
4. Team Autonomy: Multiple teams working on the same codebase creates bottlenecks. A new feature could be 10x better if implemented using a different technology or language.

The Migration Journey

Once the need to migrate to microservices has been established. The team follows careful planning and introduces incremental changes to keep the current system running during the migration process.

1. Modularize the monolith: This is a very critical step before migrating the monolith to microservices. Refactor the monolith into clearly defined modules (user, task, notification, etc) if not already done like we have in our TaskFlow example. Each should have clear interfaces, encapsulate its logic and minimized shared state.
2. Identify service boundaries: Not every module should become a microservice. You can group modules into a microservice by identifying logical service boundaries. Each service should own its data and be independently deployable. Examples of typical service from our TaskFlow platform could be:

• User service: Authentication, authorization, profiles.
• Task service: Task creation, assignment, status tracking.
• Billing service: Subscription, payments, invoice.
• Notification service: Emails, push notifications, event alerts.

3. Break up the monolith: Instead of rewriting the entire system, TaskFlow adopts a “strangler fig pattern” by gradually extracting functionalities from the monolith, routing new features to the microservice, and slowly deprecating the monolithic module.

‍

4. Data ownership and migration: Breaking a shared database for your microservice can be quite challenging. The general idea is that every service should have its own database schema or instance and should avoid direct cross-service database access. Data access and changes can be achieved through APIs and event-driven communication.
5. Communication between services: Direct communication becomes complex as the service grows. Synchronous communication for request-response flows can be achieved through REST and gRPC (for low latency internal calls) APIs. API gateways handles authentication, routing, rate limiting and serves as a single point of entry for clients. Asynchronous communication using event-driven architecture (EDA) and message brokers (eg. Kafka, MQTT, Pub/Sub) for event flows between services.
6. Infrastructure and deployment: The services are packaged into docker containers for consistency across environments. Kubernetes is used to automatically manage the deployment and scaling of the containers and each microservice has its own lifecycle and can now be deployed independently. With this structure in place, changes can be made to a microservice and deployed without the need to rebuild the entire system which leads to faster deployments. Since the services are now loosely coupled, there is low risk of regression, development and onboarding for new developers is much faster and the task and notification services in our TaskFlow platform can be scaled independently to handle the burst in traffic during peak periods.‍
7. Handling cross-cutting concerns: These are system wide requirements like security, network failures, logging, monitoring that apply to every service. These concerns are centralized using distributed tracing (e.g. OpenTelemetry), centralized logging (e.g. ELK stack), retry and circuit breaker patterns, token-based authentication (e.g. JWT) to avoid code duplication and maintenance nightmares. When it comes to data consistency, strong consistency is used only within a single microservice boundary. Eventual consistency (A few milliseconds/seconds delay is accepted for the synchronization of changes between services) is used for everything that crosses service boundaries. For example, when a task is completed in the task service, it's okay if the notification service sends a notification to concerned users after say 5 seconds later.