Restless Fingers vs. Restful Service
Pardon the interruption, we have an important message!
We are looking to expand our team with talented developers. Check out our open positions and apply.
Most of us have faced the situation when your average user just keeps pressing a button on the frontend and makes subsequent calls to a backend endpoint. Some could say it is mainly the frontend’s responsibility to prevent this situation. But it is the backend’s role to handle it if it happens.
So let’s handle the restless finger in a restful service!
In case of a Get endpoint, which is idempotent, it won’t do too much harm, just repeatedly get the same or not the same response.
If we persist data to the backend or initiate a complex operation the situation become much more serious.
Optimistic locking
In case of a simple database update we can use an optimistic record lock to handle the subsequent calls. Of course it is working only for updates.
But what can we do, if the endpoint is adding new records or starting a more complex operation: eg. make a calculation, issue an invoice and charges the user’s bankcard in one go?
In this situation our optimistic lock is unusable, but we can try to lock the endpoint itself.
Endpoint locking
The simplest implementation would be something like this:
1. Create a hash value to the given endpoint call and use it as a key
2. Check if this key is in a store (call it lockmap )
3. If it is in the lockmap, reject the request
4. If it isn’t in the lockmap, put it in and continue
5. When the operation ended, just before sending back the answer, remove this key from the lockmap.
+1. Schedule a process to periodically remove the stuck keys
Some practical notes for a java implementation:
The ideal representation for the lockmap would be a system-wide concurrent hashmap. The implementation of the ”system-wideness” is depends on the system itself, it can be a java bean or a singleton class.
As for our map entry the key can be created in various ways: from the payload and the user’s info or the username and api url, the optimal choice depends on the endpoint itself. To create the key, use some fast algorithm such as murmur hash or even the good old crc32. The value part of the entry will be the timestamp. The cleaning service will use this data to remove the stuck entries.
So go ahead and if you need to handle the “restless fingers”, give this method a try!
What do you think?
Have some comments or want to ask some questions? Share them with us via e-mail to partner@benestudio.co and we can set up a talk with our engineers.
Looking for a new job or a partner to develop your next project? Check out our open positions and our services to see what we do.
