Microservice API Design Pattern

Question

I'm new to the application architecture world. I walked through Docker's sample voting app, and see that basically everything that can be made into a modular piece, is made into one.

I'd really like to work through an example and feel that I've come up with a reasonable solution. Please correct everything in the nit-pickiest manner; I just want to improve my understanding all over on this.

Example Problem

Goal

We want an API which accepts pictures of written text, does OCR on them, looks up stuff using Google Knowledge Graph about the written words, then returns a filtered version of what we got from knowledge graph.

Modular Components

Some modular components might be:

• Receiving the request & sending back results.
• Storing received images in a database.
• Grabbing images from the DB & performing OCR on them, then committing the result to another DB table.
• Grabbing OCR results from the results table, querying knowledge graph, & storing that data in a final table.
• Sending the knowledge graph data to the caller.

Should we worry about messaging among the microservices? Probably.

Proposed design

I think this is called an aggregator microservice design pattern. The receive & send microservice will pass data to the image saver. The image saver will send a message to the OCR microservice. This, in turn, tells the KG microservice to fire. Finally, we get data back to the caller.

Thoughts & Questions

Ok. I have a lot of problems with this. To my untrained eyes, it seems like a dumb idea to have microservices here: each service needs to tell the next in the chain to fire, and none can parallelize, or fire out of order. This may as well be a monolithic API, right?

I want my thinking about this problem corrected. I'm open to any and all comments, tips, or ridicule. :)

Answer 1

You're absolutely right in questioning whether microservices are a good fit for your problem in the first place.

However, I would not rule microservices out based on the reason you've provided. Even if every request goes through a fixed series of steps, the major benefits of microservices may still apply:

• Independent scaling While you could scale a monolith horizontally if each request is completely independent, microservices additionally allow you to specialize the machines for each step.

  For example, the image analysis might not only be particularly resource-intensive but also benefit from specialized hardware. With a monolith, this hardware may not be utilized during the other steps.

• Independent deployments When an improved version of a service is available, it shouldn't be blocked because another team is not ready to deploy their new version. This is less applicable to small apps.

• Independent Technologies Because each service is run as a separate process, it's very easy to choose the optimal technology for each step. It also makes it easy to try out different technologies.

Do any of these provide a significant benefit to you? Do they provide enough benefit to offset the additional cost in complexity? I cannot give you a definitive answer, but for small apps, developed by a single individual or team, the answer is often 'no'. Also, as you noted, you want to avoid large and numerous transmissions of data between the services.

This brings us to the final issue: the service boundaries. Microservice granularity is an endlessly debated topic, but I would say your services are too small. In addition, you're using shared databases as a transport mechanism, which also isn't ideal.^*

If you decide to go with microservices, here's a possible approach for your consideration.

• An OCR service that takes an image and turns it into text.
• A Knowledge service that takes text and produces a filtered graph (maybe you can split creation and filtering)
• A gateway or orchestration service if needed.

All of this being said, I would not hesitate to go with a monolith if you don't see any clear benefits in the microservices approach. If you properly decouple your features, it should be easy enough to extract individual services later, as needed.

^{* The same seems to apply to the example you've linked to. It shows how to use docker to host stuff more than it shows a good use of microservices.}