Microservice design

In a previous publication, I wrote about the benefits of using microservice architecture. Now I want to describe the process of creating one useful microservice. Looking ahead, I will say that there will be another “microservice” article devoted to the sad result of the pursuit of technology, and not the meaning.

Task

In the test tasks from the Wheely company, I had to authenticate through the code in an SMS message. The essence of the process is as follows:

1. The user performs an action.
2. To confirm this action code is generated.
3. The code is sent in an SMS message.
4. The user specifies the key.
5. The key is checked for compliance.

The result should have been a standalone application that performs the tasks outlined in paragraphs 2, 3 (imitation only), 5 . Pins become irrelevant 2 minutes after generation. Everything else is at my discretion.

I have performed a similar task (with a different degree of study) twice already, however both times as a monolithic service, trying to use the technologies that were already in the project. In the same task it was stated that during the check particular attention would be paid to my choice of tools.

Sketch

So, I am writing a microservice that will interact with the main client application through the API. The service is based on two main components: pin creation and verification.

The dashed box highlights the components responsible for the interaction of the service with the main application.

Instruments

Database

Here you should pay attention to the low weight and short storage of the pin record. Also it is necessary to focus on the processing of a large number of codes.
')
The super-fast Redis database is ideally suited for these conditions, as well as speed, it also has an excellent expire option, which sets the record retention period. Thanks to this small option, we get rid of the code that serves the function of “delay”, and also do not load the expensive memory of our database with useless information.

Web application

We need REST, no need for views and redundant (in this case) set of "helpers" that many frameworks offer. Sinatra in this case is a very good option: a lightweight DSL under the web.

Project

In this chapter, I will talk about the microservice features of the development and I will very superficially describe the principle of operation of the application components. If readers have an interest in the process of developing the service itself, then I will try to prepare for this a separate publication.

First, we define which 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 we will write the algorithm of the components.

Create a pin

1. Sending request:
   
   

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

   
   
2. We check access on api_token.
3. We generate a unique code and add an entry to the database (SET pins: $ operation_id $ code) .
   
4. We send the message with the code.
5. We return the answer.

Check

1. Sending request:
   
   

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

   
   
2. We check access on api_token.
3. We verify the received code and the code that is stored in conjunction with the operation -> in case of success, we delete the record from the database.
4. We return the answer.

We generate answers

In this case, both of our components will return the same responses in structure. With success STATUS 200 , otherwise STATUS 403 .

Results

Great, our application accepts data, processes it and returns a response. We can assume that it took place as a microservice :)

Pros:

• The main application remains compact.
• Best for implementation (less than an hour).
• The entire system is easier to maintain and cover with tests.
• Hypothesis: increases stability. Leaving a microservice offline does not affect the operation of our product, as it simply switches to a backup service.

Minuses:

• Delay in communication via API.
• Additional resources on the patch.

I would like to finish this publication on a positive note, since in this case the result met all expectations. However, I just want to warn the reader that the microservice architecture is not suitable for everything. But that's another story.

UPD.1. Translated the format of answers from Jason to status codes. For recommendations and explanations, thanks to f0rk and smileonl .