create new table ACT_RU_TASK_METER_LOG (original proposal: ACT_RU_TASKMETRIC) with (id, timestamp, hash value of assignee)
appropriate index(es), e.g. on timestamp in ascending order
insert entry upon task assignment (every assignee change)
the assignee value will be hashed to have a predictable size estimation and to pseudonymize the inputs
hash size of 64 bit leads to a collision probability of roughly 10-12 for 6.000 UTWs (compared: 32 bit hash leads to a collision probability of roughly 0.001 for 3.000 UTWs and 0.01 for 9.000 UTWs) - see Birthday Problem for further information
create a 64 bit hash (e.g. the first 64 bit of an MD5 128 bit hash) and encode as long value (which is 64 bit as well)
data resides locally, so no security concerns regarding the hash algorithm
chosen hash algorithm should keep the collision rate as low as possible (to account for the right number of UTWs), be accessible (ideally out-of-the-box with the JDK), and as fast as possible
storing the 64 bit hash as BLOB would make "count distinct" difficult or unsupported on several DBs
storing the hash as an encoded string (hex or base64) would either increase the size (hex: 2x bit size, base64: 1.3333x bit size) or require a smaller hash (leading to a higher error rate due to possible collisions becoming more likely)
create engine configuration property to disable UTW metric
create query endpoint to aggregate UTW for a time period
create API method to query for UTW for a time period
create API method to delete task metrics by timestamp (everything prior to the given date, clean all when no date is provided)
Sub-task
L3 - Default