Design – Client-Server connection response timeout issues

client-serverdesignlanguage-agnostic

User creates a folder in client and in the client-side code I hit an API to the server to make this persistent for that user. But in some cases, my server is so busy that the request timesout. The server has executed my request but timedout before sending a response back to client. The timeout set is 10 seconds in client. At this point the client thinks that server has not executed its request (of creating a folder) and ends up sending it again. Now I have 2 folders on the server but the user has created only 1 folder in the client. How to prevent this?

One of the ways to solve this is to use a unique ID with each new request. So the ID acts as a distinguisher between old and new requests from client. But this leads to storing these IDs on my server and do a lookup for each API call which I want to avoid.

Other way is to increase the timeout duration. But I dont want to change this from 10 seconds.

Something tells me that there are better solutions.

I have posted this question in stackoverflow but I think its better suited here.

UPDATE: I will make my problem even more explicit. The client is a webbrowser and the server is running nginx+django+mysql (standard stack). The user creates a folder in webbrowser. As a result I need to hit a server API. The API call responds back, thereby client knows API call was success. This is normal scenario. Sometimes though, server successfully completes the API request but the client-side (webbrowser) connection timesout before server can respond back. The client has no clue at this point. The user thinks the request was a fail & clicks again. This time it was a success but when the UI refreshes he sees 2 folders. I want to remedy this situation.

Best Answer

Sounds like you are working in a distributed network environment, have transactions that one node expects another node to carry out reliably and you are specifically dealing/experiencing with timeouts. This is a relatively generic problem that many people had to solve at one time or another. Take a look at the three-phase commit protocol and see if that would be suitable for your application. Or possibly two-phase commit is good enough for what you are doing.

Related Topic