From Monolith to Microservices: Hospoint’s Transformation Journey

Hospoint is a healthcare system that launched with a monolithic architecture and ultimately battled with performance, scalability, maintainability, and deployment. This white paper will take you on a tour of how Hospoint transitioned to microservices. This white paper discusses how Hospoint employed the Strangler Fig Pattern, API Gateway, Kubernetes, and Docker in its migration process. It also discusses the challenges encountered and the technical solutions applied during the journey.

Introduction: The Birth of Hospoint

Mr. Kohli, who owns a software company, was approached by a friend who owns a healthcare business and requested him to develop a software for his healthcare business that would streamline patient care, handle appointment scheduling, billing, and notifications. 

This is where Hospoint was born.

The system started with the following basic needs:

• Enable patients to schedule appointments.
• Allow doctors to set their own hours.
• Remind people to reduce their no-shows.

Since Mr. Kohli’s friend was facing a lot of problems in doing all these tasks in healthcare, he demanded that this software be made as quickly as possible. Due to less traffic and functionality, the company’s engineers designed and developed it like a monolithic system. Hence, Hospoint resulted in a tightly coupled, single-codebase application.

Hospoint served successfully for several years, and numerous additional features were added to it. However, as Hospoint became more complex and its users and data increased, cracks began to appear in the system.

The Monolithic Challenge: When Growth Becomes a Bottleneck

Hospoint’s Initial System

So, Hospoint started with a monolithic design containing the below modules:

• User Management—This module is responsible for managing information for all system users like patients, doctors, staff, and admins.

• Appointment Scheduling—This module of Hospoint manages appointments based on the doctor’s availability.

• Billing System—This module takes care of the insurance claims, invoicing, and payments.

• Notifications—This module is solely responsible for sending appointment reminders and alerts.

• Database—This is the whole sole database for Hospoint, which stores all the data.

With the rise of complicated business logics, users, and data in Hospoint, the following pain points began to emerge.

• Scalability  Bottlenecks: Even if only one module needed to be scaled, the entire application had to be replicated.  Increased demand for appointment scheduling also has an impact on unrelated modules such as authentication.

• Deployment Risks & Downtime: A minor modification in one module necessitated redeploying the entire system, raising risk.

• Maintenance Complexity: Managing the increasing codebase became challenging, slowing down progress.

• Challenges with Data Consistency: Using a single database creates bottleneck for whole system and can become a single point of failure.

• Performance Issues: Appointment scheduling slowed down due to resource congestion brought on by notification procedures.

The engineering team realized that it was becoming increasingly difficult to offer new features without affecting other aspects. Downtime and crashing became regular.

Now is the time to ask, “Is there a better way?”

The Shift to Microservices: A Transformation Journey 

The response to the query, “Is there a better way?” 

The modules were to be separated into distinct services that would be loosely coupled. This is when Hospoint’s path towards microservices architecture began.

This raised the question: Why microservices?

The technical team determines that migrating to microservices will resolve the Hospoint issue listed below. 

• Independent scaling: the ability to scale each module individually.

• Independent & Quicker Development & Deployments: Develop and release any module without affecting others to enable faster iterations and lower risk.

• Resilience and Fault Isolation: If one service fails, the system as a whole shouldn’t be impacted.

The Strangler Fig Pattern: A Step-by-Step Migration

Hospoint used the Strangler Fig Pattern to gradually replace monolithic modules with microservices rather than rewriting everything all at once.

 Step 1: Identifying Service Boundaries

 Step 2: Gradual Migration – Strangling the Monolith

Step 1: Identifying Service Boundaries

The Hospoint system is thoroughly evaluated before the team begins developing microservices, and the logical service boundaries are determined below.

• User Service: This service will handle system users like   doctors, patients, administrators, and hospital staff.  

• Appointment Service: This service will handle appointment booking, rescheduling, and cancellations.

• Notification Service This service will handle various forms of alerts, such as system appointment reminders sent via email or SMS.

• Billing & Payment Service: This service will handle billing and payments.

Step 2: Gradual Migration – Strangling the Monolith

The team utilized the Strangler fig approach to transition Hospoint from monolithic to microservices.

The Strangler Pattern is a software migration technique where a newer system progressively enhances an older system, enabling the two systems to operate concurrently until the older system is completely decommissioned.

• Begin Small: Notification, the most disconnected and low-risk service, was the team’s first offering.

• API Gateway: The team then used API Gateway to route queries to either new microservices or monolithic applications, and then to all new microservices.

• Incremental Migration: Next, the team progressively switched to the microservices design for the remaining modules as well.

Hospoint’s Microservices Architecture

New System Overview

The new Hospoint is now migrated to new microservices based design which includes below

• API Gateway – Handles authentication, requests and routing.

• Independent Microservices – Each service (User, Appointment, Billing & Notifications) runs separately.

• Docker & Kubernetes – Manages containerized service

Deployment Flow: From Code to Production

This transition unlocked true scalability for Hospoint.

Overcoming Technical Challenges

The engineering team encountered multiple challenges during the Hospoint migration from monolithic to microservices, which they overcame in this way.

1. Data Consistency: The Distributed Data Dilemma

Because there is only one database in monolithic systems, it was simple to maintain consistency. However, because each microservice has its own database, data resides over several databases, making consistency difficult to maintain.

Let’s understand this with a problem statement:

When the patient tries to book an appointment

• First Appointment Service reserves the time slot.
• Then Payment Service charges the patient.

If payment fails, the appointment must be canceled, but databases for both services are different, so how do you manage consistency across services?

Solution: 

The team implemented the Saga Pattern.

Saga Pattern: Data consistency is maintained by executing a sequence of separate, compensatable microservice actions in a distributed transaction management system.

• A patient books an appointment (Appointment Service).
• Appointment Service is notified.
• Once the doctor’s availability is confirmed.
• Billing Service is notified to process payment.
• If payment fails, a cancel message is sent to the appointment booking service to cancel the appointment.

2. Service Communication: Sync vs. Async

Now as Hospoint is divided into multiple services, these services needed to communicate with each other. There are two ways to communicate between services.

📌 Synchronous (REST API):

• Used for real-time interactions (e.g., fetching patient details, authentication).
• Downside: Services depend on each other, causing failures to propagate.

📌 Asynchronous (Kafka Event):

• Used for background tasks (e.g., sending appointment reminders).
• More resilient and scalable than synchronous calls.

Let’s understand service communication with a problem statement:

If Appointment Service depends on Payment Service via synchronous REST calls, failures cascade if Payment goes down; appointments cannot be booked.

Solution:

Appointment and payment services will communicate via Queue (e.g., Kafka) to decouple services so retries or cancellation of appointments can happen asynchronously.

3. Observability & Monitoring: Keeping the System Healthy

Since monolithic service events were sequential and generated in the same location, they were easier to read and understand. Because microservices are asynchronous and each service has its own logs, debugging becomes harder. In addition, microservices maintain eventual consistency.

Let’s understand this with a problem statement:

Tracking a patient’s appointment from booking to notification required investigating data from multiple logs.

Solution:

• Logging: Use centralized logging like the ELK (Elasticsearch, Logstash, Kibana) stack.

• Metrics & Alerts: User real-time monitoring tools like Prometheus + Grafana, Dynatrace.

• Distributed Tracing—Use tools like OpenTelemetry, Jaeger, Zipkin, and Dynatrace to trace API calls across multiple services.

Above prevents Hospoint failures before they impact users and it’s now easier to debug system in case of any error.

4. Deployment Complexity – Managing Services at Scale

With monolithic services Hospoint’s deployment was simple because it was a single application. However, the shift to microservices makes manual deployment unmanageable.

Using a problem statement, let’s examine service communication:

Coordinate manual releases across many services. Multiple occurrences might cause confusion, resulting in downtime and system instability.

Solution:

• Containerized Services: Use a containerization tool like Docker to package each service. It’s fast and quick to deploy.
• Automated Deployments, Scalability, Health Checks, and Service Discovery: Use orchestration tools like Kubernetes for container (service) orchestration, scaling, discovery, health checks, and networking. 

When to Use (or Avoid) Microservices

✅ Use Microservices When:

• You need independent scalability for different modules.
• You have a large team and need faster, independent deployments.
• Your business has complex domain logic.

❌ Avoid Microservices When:

• Your system is small and manageable.
• You don’t have the expertise to manage microservices complexity.
• You don’t have clear service boundaries.

For Hospoint, microservices were the right choice. But not every company needs them.

Key Takeaways

📌 Microservices enable scalability but increase complexity.
📌 Strangler Pattern minimizes migration risk—start small and expand gradually.
📌 Monitoring and observability are crucial—logging, metrics, and tracing prevent failures.

Hospoint successfully scaled while maintaining system resilience and developer agility.

Conclusion: The Future of Hospoint

Since migrating to microservices, Hospoint has seen:

🚀 99.9% uptime (compared to frequent monolithic crashes).
⚡ 30% faster feature delivery due to independent deployments.
📈 Cost savings on infrastructure by scaling only necessary services.

Microservices enabled Hospoint’s next phase of growth, ensuring a seamless healthcare experience for patients.

Call to Action (CTA)

🚀 Is your organization ready for microservices?
👉 If you’re facing scalability and deployment bottlenecks, consider a step-by-step migration strategy.