System Init
0%
LOADING_ASSETSv2.0.26
blogs/microservices-vs-monolith-dalam-mengatur-jadwal-kuliah
//Khay
Baca Bahasa Indonesia

Microservices vs Monolith in Managing College Schedules

ProgrammingSystemDaily

Yesterday I saw my friend open his phone calendar, and I swear that calendar looked like legacy code that has not been maintained since 2010. Everything was piled up into one massive block: class schedules, assignment deadlines, gym sessions, hangout appointments, even the schedule to call his mom.

Then he complained to me that he feels his life is falling apart. If just one schedule is fifteen minutes late, every schedule after it instantly falls apart like a domino effect.

I took a deep breath. Bro, your problem is actually purely a system architecture problem. You are running your life using a Monolith architecture.

For those who do not know, Monolith is an old-school approach in the software world where all application functions are built inside one giant container. If one feature errors out, you have to restart the entire server. Just like my friend's life earlier. He woke up late (alarm feature error), resulting in him being late for his morning class, his assignment not getting printed in time, his mood ruined for the gym, and his night hangout getting canceled. One single failure point destroyed his entire daily system.

So what is the solution? Of course we need to refactor to a Microservices architecture.

Microservices break down a large application into small, independent services. Each service has its own database, its own logic, and can be deployed without disrupting other services. If the chat feature errors, the payment feature keeps running. When applied to college schedules, this brings extraordinary efficiency.

How to implement it is easy. First, separate your life domains into several services. For example: AcademicService, HealthService, and SocialService.

Second, make them loosely coupled, meaning do not make them too dependent on each other. Do not make an appointment to do group work exactly five minutes after class ends. Give it a buffer or break time. This is like you providing an API gateway to manage traffic so your server does not overload. If your lecturer is 20 minutes late finishing class (which is a daily occurrence on my campus), your SocialService will not immediately throw an error because you have a 30-minute buffer.

Third, apply the principle of fault tolerance. If one service goes down, your life must keep running. For example, your AcademicService is currently ruined because you got a D on a quiz. Do not let this ruin your HealthService. You still have to eat lunch and get enough sleep. In a Microservices system, if one service dies, there is a fallback mechanism. Do not let your life be a single point of failure.

But it is true though, Microservices do feel more complicated in the beginning because you have to manage many components. You need an orchestrator like Kubernetes to make sure everything runs harmoniously. In the context of your life, Kubernetes is your own mental discipline. You need to know the priority of which service is critical and which can be delayed.

If you feel your schedule is too complex, you better re-audit how you arrange your activities. Perhaps you are forcing an outdated architecture to deal with dynamic modern problems.

  • Khay