From Chaos to Clarity: A Guide to Defining Microservices Boundaries

📖 Previously in Hospoint: The Great Migration

We saw Dr. Emily, the owner of a healthcare system, request his friend Mr. Kohli, the owner of a software firm, to create a software system for her healthcare.

Mr. Kohli architected the system from monolith to microservices.

It was architected properly, but at first the engineering team didn’t fully understand the architecture and create the microservices.

Remember the system split into the below microservices.

• User Service: Managed doctors, patients, administrators, and hospital staff.
• Appointment Service: Took care of booking, rescheduling, and cancellations.
• Notification Service: Sent appointment reminders and alerts.
• Billing & Payment Service: Handled billing and payments.

🎉 At first, it seemed like a success! Now, each service has its database and can be scaled and deployed independently. Engineers can now deploy changes faster without affecting the entire system.

But…..

The Day Hospoint Broke!

One fine morning, Dr. Emily came to the hospital for saving lives. But something was wrong.

• The Appointment Service couldn’t find patients because it needed data from the User Service, and due to heavy load, it’s stuck.
• The billing service froze because it was waiting too long for the appointment service to confirm visits.
• The notification service is overloaded by the messages bouncing back and forth between services.

Remember our LEGO diagram

It looks like we tried building a LEGO hospital, and all the pieces are keeping running away from each other.

So, the new problem is:

👉 How do we define the right service boundaries so microservices actually work?

Welcome to the next chapter of Hospoint’s transformation… 🚀

Mr. Kohli Saved the Day!

Now both Dr. Emily and the engineering team look back to Mr. Kohli for help.

After carefully reviewing the code and the low-level diagrams, Mr. Kohli took everyone to the whiteboard again.

“You are focusing only on the technology. Just look at how health care is working.”

Mr. Kohli started drawing again:

• The User Service should only and only care about managing people – doctors, patients, staff, and admin.
• The Appointment Service should focus on scheduling, not on storing patient records.
• The Billing & Payment Service needs to generate invoices and process payments and not interfere in patient details.
• The Notification Service should send alerts without waiting on every little detail.

Mr. Kohli explained with a smile that this approach is called “domain-driven design (DDD)”. Instead of breaking things randomly, the service should be separated based on how the real system is working.

So, Hospoint services should be divided the same way as hospitals. It should mirror how hospital departments are working.

The Smart Fix: The New and Improved Hospoint

Understanding the domain-driven design concept from Mr. Kohli, Hospoint services are now planned mirroring how healthcare was working.

• User Service: Managing only patient and staff data.
• Appointment Service: Dedicated only for scheduling appointments.
• Billing & Payment Service: Focused on processing payments only after an appointment is confirmed.
• Notification Service: In charge of sending out alerts and reminders without interference.

One more thing that Mr. Kohli advised for every service. He suggested that instead of each service calling each other like a video or audio call, they switch to “Event Driven Architecture.”<link to event driven system>

So, every service is connected to a queue and listening to multiple topics without waiting for any other service to respond or creating a chain reaction of delays.

So, in case an appointment is booked:

1. Appointment service is creating an event “Appointment Created” and sending it to the relevant topic.
2. The billing service picks this event up from the topic and starts processing the payment.
3. Once the payment is done (“Payment Done Successfully”), a new event is created and pushed to another topic that is subscribed to by “Appointment Service“.
4. Once the event is picked up by Appointment Service, it confirms the “Appointment Service” and again creates an event “Appointment Confirm with other details”. This event is read by “Notification Service” and sends a message to the patient for order confirmation. And only this service will be responsible for sending a reminder to the patient for the appointment until the “Appointment Cancel or Reschedule” event is received.

Happily Ever After

• After all the microservices are re-structured and code was updated.
• Patients got the appointment confirmation and notification on time.
• Hospital staff can concentrate on their core competency and not on the chaos.

Dr. Emily is now happy because she is now able to understand Hospoint as it’s working in sync with his healthcare.

So, 

Think like a hospital, not like a computer.

What Did We Learn?

✅ If microservices are not architected properly, they can create chaos.

✅ Think of services as real business and not like a technical separation.

✅ Using event-driven design can help services communicate without holding other services.

✅ Always keep in mind—change is the only constant. So, your system and design should evolve.

Would you like to explore how to draw the perfect service boundaries in your own projects? Read the Golden Rules of Microservices.

Final Thoughts & Call-to-Action

🚀 If you found this story fun and helpful, share it with your friends! Let’s turn every spaghetti-monster system into a well-organized, event-driven success.

💬 Got questions about your own microservices design? Drop them in the comments, and let’s discuss!