‘Should I make it a Microservice?’

‘Hmm I’m not sure whether to make this orange one a Microservice or maybe just keep it simple as a package’?

Often when considering, or working with Microservices, we are uncertain whether some component should be a Microservice. This component might be a mailer, price calculator, facebook connector, message queue facade, or anything that seems to benefit from being an autonomous component.

The checklist below means to give a sense of whether you need a Microservice or maybe it’s probably an overkill tool for your needs and you can deploy it as a package or maybe even just another class/object.

Although all the reasons below are valid and essential to consider, take the ‘gamification’ and scoring part with a sense of humor.

Answer all the questions and sum your score

Start with 0️⃣

Move to the next question 👇

2. Different teams: Will a different dedicated team develop this component?

If YES: add 10 points

Move to the next question 👇

3. Dedicated technology: Is the component likely to be developed using a different programming language?

If YES: ➕ add 20 points

Move to the next question 👇

4. Simplicity: When not extracted out, do things get too complex to “fit in your head”?

If YES: ➕ add 10points

Move to the next question 👇

5. Failure isolation: Should and can this component stay alive and provide value when its collaborators crashed?

If YES: ➕ add 7 points

Move to the next question 👇

6. Operational complexity: Do you already have a Microservice infrastructure?

If YES: ➕ add 5 points

Move to the next question 👇

8. Granular deployment: Is this functionality likely to be updated at a different pace than other components so you can update it without the need to update its collaborators?

If YES: ➕ add 12 points

Move to the next question 👇

9. Stateful service: Does it expose API, DB or any other stateful activity?

If YES: ➕ add 3 points

Move to the next question 👇

10. Ubiquitous language: Is this functionality represents an isolated product domain like a stand-alone feature or having a dedicated product manager?

If YES: ➕ add 3 points

Move to the next question 👇

11. Independent scale: Is this component’s traction is likely to be different than others and might need to scale independently?

If YES: ➕ add 20 points

Move to the next question 👇

12. Dedicated infrastructure: Does the component deserver a unique hardware spec like GPU or extensive RAM support?

If YES: ➕ add 20 points

Move to the next question 👇

13. Change protection: Might this component get replaced sometime soon by another implementation, for example by a 3rd party product?

If YES: ➕ add 3 points

Move to the next question 👇

14. Avoid chatty flow: Is this functionality invoked multiple times during each flow (e.g. log, trace, etc)?

If YES: ➖ subtract(!) 20 points

Move to calculate your results 👇

🗒️ Results — should it be a Microservice?

0–5 points

5–10

10–15

15–20

20–30

30–50

Final wording

I’m curious, did the score made sense? feel free to suggest improvements

Stay in touch

Node.js best practices — 79 best practices for a robust Node application

45+ JavaScript testing best practices

Software Architect, Node.JS Specialist. Consultant, blogger, conference speaker, open source contributor — author of the largest Node.js best practices guide

Software Architect, Node.JS Specialist. Consultant, blogger, conference speaker, open source contributor — author of the largest Node.js best practices guide