Home Development of Websites Designing a microservice

Designing a microservice

by admin

In a previous publication, I wrote about The advantages of using microservice architecture.Now I want to describe the process of creating one useful microservice.Getting ahead of myself, I will say that there will be another "microservice" article about the unfortunate result of chasing technology rather than meaning.


In a test task from Wheely, I had to implement authentication through a codein a text message.The essence of the process is :

  1. The user performs an action.
  2. A code is generated to confirm this action.
  3. The code is sent in a SMS message.
  4. User specifies a key.
  5. The key is checked for a match.

The result should have been a standalone application that performs the tasks outlined in 2, 3 (simulation only), 5 The pins become irrelevant 2 minutes after generation. Everything else is at my discretion.
Designing a microservice
I’ve done a similar task (with varying degrees of elaboration) twice before, but both times as a monolithic service, trying to use the technologies that were already in the project. The same assignment stated that my choice of tools would be the focus of the review.


So, I’m writing a microservice that will interact with the main client application via API. The service is based on two main components : the creation of the pin and its verification.
Designing a microservice
The dotted frame indicates the components responsible for the interaction between the service and the main application.



Here you should pay attention to the low weight and short storage time of the pin record. It is also worth focusing on processing a large number of codes.
Perfect for these conditions is a super-fast DB REDIS because in addition to speed it has a great option expire, which defines how long a record will be kept. With this small option we get rid of the code for the expire function, and we don’t overload the expensive memory of our database with useless information.

Web application

We need REST, we don’t need views or the redundant (in this case) set of "helpers" that many frameworks offer. Sinatra in this case a very good option : a lightweight DSL for the web.


In this chapter I will talk specifically about microservice development and will describe very superficially how the components of the application work. If you will be interested in the service itself, I will prepare a separate publication for it.
First let’s define what parameters will run inside our service :

  1. api_token – application key;
  2. operation_id – unique operation code;
  3. phone – phone number;
  4. code – n-digit verification code.

Now let’s write the algorithm for the components.

Create pin

  1. Sending a request :
    POST 'https://test.dev/api/v1/pins', api_token: 'zx..d', operation_id: 'cs12', phone: '79..1'

  2. Checking access by api_token.
  3. Generate unique code and add it to the database (SET pins:$operation_id $code)
  4. Send message with code.
  5. We return the reply.


  1. Sending a request :
    POST 'https://test.dev/api/v1/pins/cs12/check', api_token: 'zx..d', code: '2213'

  2. Checking access by api_token.
  3. Compare obtained code and the code, which is stored in the -gt operation; if successful, delete the record from the base.
  4. Returns the response.

Generating answers

In this case, both of our components will return the same structure of responses. If successful STATUS 200 , otherwise STATUS 403


Great, our application receives data, processes it and returns a response. We can consider it as a microservice 🙂
Pros :

  • The main application remains compact.
  • Optimal for implementation (less than an hour).
  • The whole system is easier to maintain and cover with tests.
  • Hypothesis : stability is improved. A microservice going offline does not affect our product in any way, because it simply switches to a spare service.

Minuses :

  • API communication delay.
  • Additional resources for deplot.

I want to end this article on a positive note, because in this case the result met all expectations. However, I want to warn the reader right away that microservices architecture is not suitable for everything. But that’s another story.
UPD.1. Moved the response format from jason to status codes. Thanks for the recommendations and explanations f0rk and smileonl

You may also like