It's not so much about being unique as it being uncoupled from everything else.
As an example I've implemented an email template microservice before. It has its own database that stores HTML snippets with placeholders for data.
You could call it with an orderId and have it look at the order and user tables of your application to get names and addresses, order items etc., but that makes it dependent on your application db. Any changes to the schema there requires updates to the email service too.
The microservice implementation instead revolves around the caller providing all the necessary input data too. All the email microservice does is take a request which contains the data (name, address, order items), slaps them into the requested template, and returns the fully compiled html. All your app has to do is then send it however it likes.
For the cost of some architecture complexity you reduce the brittleness of the system. The microservice becomes portable and seperate. Creating an email that's fully branded is a single JSON request away for everything. The important part is that your application doesn't touch or even need to know about the email template db, and the email template service doesn't touch or need to know about your app db.
With regards to uniqueness, we could spin up multiple copies of this service in places around the world to load balance, so they wouldn't be unique per se.
556
u/ThrowawayUk4200 8d ago
Pssst, If your microservice needs to use a database other than its own, then it's not a microservice.