Potent Idempotence

April 25, 2021

Idempotence is defined as an action which, when performed multiple times, has no further effect on its subject after the first time it is performed. Kind of abstract but it does have some real life uses in software. The following will walk you through how Qubkl utilizes idempotence and how it’s implemented.

The canonical example of idempotence is online payments. A payment could delay or fail for muliple reasons and you wouldn’t want the user to spam the same payment while its processing. If you have a unique id for the submitted payload, you can avoid processing any payment with the same id. This helps you avoid reversing charges and helps the user avoid depleting their credit limit or account balance.

Qubkl uses idempotence to avoid duplicate Excel renders. When a user renders to Excel we save that spreadsheet to AWS S3. With spreadsheet sizes hitting up to 5 megabytes in size, idempotence allows us to avoid re-rendering spreadsheets that have already been rendered. It also eliminates the potential wait time for rendering scenarios that have already been rendered. If our idempotence key already exists we just point the user to the previous render.

So how do we create the key? We use the SHA hash of the entire state of the current analysis. In Qubkl’s React front end, we jsonify the entire state and hash it resulting in something that looks like this: 2346ad27d7568ba9896f1b7da6b5991251debdf2. We then use the SHA hash as the unique identifier and check that against the hashes of previous payloads used for previous Excel renders.

Using SHA hashes helped us avoid setting up and calling out to another service and has the added bonus of being implemented in most languages. After implementing this for the render we’re finding other uses for the SHA that we’ll cover in another blog post.