Let's say I have a mobile client for answering questions and then purchasing a widget. For example, I might have 10 screens from my UI with about 8 questions per screen. Imagine there is a screen for first name, last name data, 'create personal information' is basically the operation/service call.

With REST, JSON over HTTP microservices, the thought is that you might have a service for that particular 'create person' request and then we would save to some database. That request may take in 10 properties for that particular call.

This is a simple example and use-case with not a lot of detail, but here is the general question. Let's say there is an API embedded in this application, one for collecting questions about a person. And the other is for making a purchase. When you are working with mobile native clients, should the client talk directly to the microservice which in term may flow to the database in one synchronous operation? I was also looking at the approach of an event-driven model for microservices, is an asynchronous approach preferred?

2 Answers 2


My preferred approach is to provide a single api per client (one for mobile clients, another for web clients, desktop, etc.). In your case (for now anyway), it'd be one api per native mobile clients.

Note that each type of client might have different requirements and capabilities, authentication method, serialization, headers, etc. Your microservices shouldn't be concerned about these things, the same way that your client shouldn't be concerned about your ever changing distribution of microservices.

You can achieve this by coding a dedicated api which provides the right interface for your client and calls the required microservices, or you can use a gateway service like Azure API Management or similar, which allow you configure the mapping between the endpoints exposed to your clients to your internal microservices.

  • Normally when I think of the client calling some API endpoint. I think that mobile UI might make a synchronous http request call that hits some backend endpoint and the flows through to the database. I am not using API management, but maybe look into those. Are you using asynchronous event based communication with your mobile clients and how does that work? Feb 18, 2018 at 3:43
  • I'd say all reads should be synchronous and writes can be either synchronous or asynchronous. Asynchronous commands (the http request simply places a message in a queue and returns OK) are more reliable (placing the message to the queue will likely succeed and processing the message in the background will benefit of retries, so it will succeed even if there are glitches on the DB or network). But asynchronous processing has the main problem of figuring out how to notify back to the client when the operation has completed. You could use simple polling, SignalR, push notifications... Feb 18, 2018 at 19:46

If this is some kind of telemetry, which is not cruical to the purchasing than you should probably have 2 microservices (telemetry linked to purchase by some ID, and the purchase). Each microservice has it's own API but that doesnt mean you can't make a facade on the Api Gateway to actually invoke those 2 microservices for you...

If this is some info that MUST be availabile at the purchase then IMO it's a one microservice and it definitely is one API call... (transaction?)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.