• notice
  • Congratulations on the launch of the Sought Tech site

Distributed system interface, how to avoid repeated submission of forms?

How to implement a system that carries more users has always been a technical direction that I focus on. Renovating the structure to improve the bearing capacity is generally divided into two major directions, which are realized in cooperation with each other.

The improvement of the hardware architecture is mainly achieved by using the multi-component cloud environment of Alibaba Cloud: through load balancing SLB, cloud server ECS cloned from the template, cloud database RDS, shared object storage OSS and other cloud product combinations with different responsibilities.

Software architecture optimization, mainly the specification of software code development: business decoupling, architecture microservices, stand-alone stateless, file storage sharing, etc.

In the learning process of distributed systems, I also continue to see new knowledge points. What I want to talk about today is the realization of "idempotence" for interface services during software development!


Effect: The system should return the same result for multiple requests to an interface! (Except for scenarios where network access fails)

Purpose: To avoid repeated business processing caused by repeated requests for various reasons

Repeat request scenario case:

1. After the client makes the first request, the network exception causes the request to be executed but the logic is not returned to the client, and the client re-initiates the request

2. The client quickly clicks the button to submit, causing the same logic to be sent to the server multiple times

Simple division, business logic can be summed up as adding, deleting, modifying and checking!

For queries , there are no other operations inside, and the kind of business that is read-only must meet the requirements of idempotence.

For deletion , repeated deletion requests will at least not cause data clutter, but in some scenarios, it is more desirable for repeated clicks to prompt that the deletion is successful, rather than the prompt that the target does not exist.

For new additions and modifications , here are the parts to focus on today: new additions, need to avoid repeated insertion; modification, avoid invalid repeated modifications;

How to achieve idempotence

Implementation method: When the client makes a certain request, it brings the identification parameter identification, and the server identifies the identification, and repeats the request and returns the first result repeatedly.

Take a chestnut: For example, in the add request form, when the add form page is opened, an AddId identifier is generated, and the AddId is submitted to the background interface along with the form.

According to the AddId in the background interface, the server can mark and filter the cache. The cache value can be AddId as the cache key, and the returned content as the cache Value, so that it can be identified even if the Add button is clicked multiple times.

When will this AddId be updated? Only after the save is successful and the form is cleared, the AddId identifier is changed to realize the form submission of new data.


Technical otaku

Sought technology together

Related Topic


Leave a Reply