Is a outlook type calendar/scheduling service a microservice?

Question

Our company is in the early stages of starting to use microservices. One question that came up the other day was 'is scheduling/calendar a micro service'?

We have so many monolithic apps that have built their own calendar/schedule - some allowing appointments to be scheduled in the morning and afternoon and some more granular where like outlook you can pick 1/2 hour slots. So we have many monolithic web apps which have an outlook UI where some UIs select a slot and in some others they drag a region to create an appointment.

That is a lot of duplication all doing roughly the same thing at the back end.

So should we build one single scheduling service and use it across the company as a microservice?

Answer 1

A microservice is a responsibility that has behaviors and persistence. You're calling out the duplicated behaviors by the various monolithic apps, but I wonder about the persistence side. What persistent data do the monoliths have that supports their scheduling? If this state is also duplicated then yes, seems like a microservice would be better. Otherwise, it still might make sense, but teasing that persistence out could be challenging.

Ultimately, it is a business & engineering decision, which should include build vs. buy (as this may not be at your company's core differentiation, and someone must be selling scheduling capabilities), as well as cost of refactoring the monoliths, and whether you are planning on going to microservices anyway.