In our previous blogs, we saw how Hospoint transformed from a struggling monolith to a microservices system. We also explored how to define the right service boundaries. Let’s go ahead and ensure these boundaries truly stand with time too.
Dr. Emily invited Mr. Kohli and the engineering team to the hospital lounge for a small party for fixing Hospoint. While everybody was happy, the application lead looked worried.
“What’s wrong?” Dr. Emily asked.
The app lead replied, “We fixed our system with the help of Mr. Kohli, but every system is different. How do we ensure that other types of businesses are also dividing their services the right way?
“Hmmm. Valid point,” Dr. Emily said. Let’s ask Mr. Kohli.
“Trust the domain,” said Mr. Kohli, smiling and sipping his tea. ☕️
Tell us more, said the lead…
Ok, let me take you to ”The Temple of Good Design,” where you will find the hidden “Golden Rules of Microservice Boundaries,” but you need to go through the problem to find them.
Mr. Kohli has taken a pen and a notebook out of his bag.
Problem 1: The Curse of the Shared Database
Mr. Kohli drew two services and one database and added twisted wires between services and the database.
Mr. Kohli said, Here is the problem with this system:
“If your services share a database, you shall face… THE CURSE OF COUPLING!”
The solution is, Mr. Kohli said, “Each service should own its data and expose it through APIs!”
Lesson Learned:
Never let multiple services directly share the same database—it creates tight coupling and hidden dependencies.
Problem 2: The Tricky Trap of Tiny Services
Mr. Kohli now opened another paper and filled the paper with lots of small boxes and asked, “Smaller is better… or is it?”
Mr. Kohli named a few boxes.
Service One—Responsible for Name
Service Two—Responsible for address
Service Three—Responsible for allergies
Service Four—Responsible for blood pressure.
The lead immediately said: But some things belong to each other and creating such granule services will result in endless network calls and can create a chain of reaction for delays.
Dr. Emily jumped in too—same as we doctors don’t need to have separate appointments for height, weight, and blood pressure. They are part of the same checkup.
Mr. Kohli said, Services should be small but not too small.
Lesson Learned:
Microservices should be right-sized—too big a service is a monolith, too small is chaos.
Problem 3: The Test of Real-World Boundaries
Time for page 3 of Mr. Kohli’s notebook.
He now created two services. Billing and patient management. He also created two rough screens where booking is after the payment screen.
Before the lead, Dr. Emily said, Hospital doesn’t work like that. You check the availability first, confirm your will for an appointment, and then make the payment to confirm the appointment.
Mr. Kohli stated, “If your services don’t match the business, they will crumble.”
The application lead said, “Use domain-driven design (DDD) to define the boundaries for real-world business.”
Lesson Learned:
Services should be split based on real business functions, not based on technical.
Problem 4: The Communication Puzzle
Mr. Kohli asked Dr. Emily what if there is one hospital that is not communicating with any other hospital?
Dr. Emily replied that hospital won’t get any updates or new technologies used by other hospitals and will be outdated.
Mr. Kohli questioned again: What if a hospital is calling other hospitals a lot and in a very short interval?
Dr. Emily thought a bit and said no one will pick up the phone, as it will keep hospital staff busy chatting to that hospital, and it hampers the work.
Mr. Kohli smiled and looked at the application lead. The same happens with microservices.
If a service is working in isolation, that means it’s not sharing any updates with other services, so it’s of no use.
If a service is calling other services very frequently, then it will create delays and crashing of other services. So, we need a balance in the communication.
Mr. Kohli took a sip of his tea and said,.
- If the need is to call any service in real time or in urgency, only then use direct API calls; otherwise,
- Use event-driven messaging for asynchronous communication or updates.
Mr. Kohli told the application lead that if
Lesson Learned:
Services communication should be done based on the need and not for the sake of communication.
“A microservice boundary should follow business processes, own its own data, be right-sized, and communicate efficiently.”
Keep up the best work.