I’m running a worker that handles form-submission.
The configuration of what needs to happen when the form is submitted is stored in Google-Firestore.
Because this is a critical path of the application, I’d like to minimize dependencies, and do as much as possible in Cloudflare environment. Therefore I thought to have a replication of the form configuration in Workers KV.
So when the user publishes form configuration, the server will save the form configuration in KV.
Then, when a form is submitted, the submission goes to a worker that will load the form configuration from kv and will know what to do with it.
My problem is that sometimes users make changes to a form, then publish, and then immediately try to test their changes. Because kv is eventually-consistent, and can take a long minute before changes are reflected in read operations, users may now understand why they don’t see their changes applied.
I thought maybe instead of updating the same key I should publish changes to a new key with the same prefix. For example
<formid>_<date>, then list all keys and take the last one. But from this thread I understand that
list suffers from the same eventual-consistency issue that changes to an existing key suffers.
So this option was ruled out.
Another idea I had was to write each change to a separate key as before, but instead of
listing all keys by prefix, I will have a cache-key that points to the last kv key. When the user publish changes to a form config, I will create a new kv key with the form-config, and will update a cache-key to point to it.
Will that work? Do cache
put immediately reflected for workers or can it also take a minute to propagate?
Any idea or input is welcome.