Our current tombstoning API tombstone_value_states accepts a list of ValueState keys that tombstoning should be performed for. This means that the client flow will, more often than not, involve:
looking up all ValueState objects for a given user in DB
figuring out which objects should be tombstoned based on their epochs (relative to the current epoch)
passing the keys of said objects to the tombstone API
Internally, the tombstone API then does another lookup of ValueState objects with the keys passed, modifies the objects to "tombstone" them, then another write to commit the now-tombstoned objects.
Proposed
We can cut out the DB lookup pre-API call by having the API take in an epoch and a username, then tombstoning all ValueState objects for the user with an epoch less than or equal to the passed epoch. Clients will not need any knowledge of what ValueState objects a user has, and just need to inform the API which epoch to stop tombstoning at.
In addition, before we write the tombstoned records, we should filter out any objects that are already tombstoned, to avoid unnecessary writes.
Current
Our current tombstoning API
tombstone_value_statesaccepts a list ofValueStatekeys that tombstoning should be performed for. This means that the client flow will, more often than not, involve:ValueStateobjects for a given user in DBInternally, the tombstone API then does another lookup of
ValueStateobjects with the keys passed, modifies the objects to "tombstone" them, then another write to commit the now-tombstoned objects.Proposed
We can cut out the DB lookup pre-API call by having the API take in an epoch and a username, then tombstoning all
ValueStateobjects for the user with an epoch less than or equal to the passed epoch. Clients will not need any knowledge of whatValueStateobjects a user has, and just need to inform the API which epoch to stop tombstoning at.In addition, before we write the tombstoned records, we should filter out any objects that are already tombstoned, to avoid unnecessary writes.