Redis Cluster compatibility #8
Description
The DB would have to be restructured again:
- All the current data we track separately (match, offer-answer, offer-reply-location, etc) will be put in a Hash under the ID/name we request against (a bit like the original DB scheme). This also means we have to go back to storing redundant indexes again (for the same reasons as before).
- The web server will perform an initial HGETALL for the data, then on reception, construct the relevant keys and call the relevant script with those keys.
This still fixes the race conditions etc (as all the transformative operations still happen synchronously and can re-check), albeit with slightly more latency.
One big upshot of a new model like this is that refreshing all the data together takes one TTL call instead of the pexpire monstrosity in the current uuidGet script.