bigtable-concurrency.txt

/**
 * Bigtable schema layout for concurrency ticket managment
 * One key per queue shard to store the current list of holders, like `holders#<some-hash>#e:environmentId#q:queueName#s:shard`
 *  - queue id is the row key
 *  - shard id that splits up high concurrency queues for one tenant into many different shards, currently running with shards of size 20, so a tenant with 200 max conurrency gets 10 shards
 *  - `agg:holderCount` column containing the number of current holders
 *  - dynamic columns per current holder, using the particpant id as the column qualifier, having the workflowid as a value
 *  - hash is added up front to ensure that shards for the same tenant with correlated load go to different tablets
 *
 * One key per requester to store the list of waiting tickets, like `req#<some-hash>#e:environmentId#q:queueName#s:shard#priorityScore#enqueuedTimestamp#requesterId`
 *  - queue id / priority score / enqueuedTimestamp / requester id is the row key, so its sorted by priority and then enqueue order for fast range scans to get the next dequeue
 *  - shard id that splits up high concurrency queues for one tenant into many different shards, currently running with shards of size 20, so a tenant with 200 max conurrency gets 10 shards
 *  - fixed columns within this row for tracking all the ticket details like workflow id, connection name, and recorded at
 *  - hash is added up front to ensure that shards for the same tenant with correlated load go to different tablets
 * 
 * The keys for a queue named "some-queue-name" for environmentId 123 might look like:
 *
 * `holders#deadbeef#e:123#q:some-queue-name`:
 *  - has a `agg:holderCount` column
 *  - has `holderids:id-111` column tracking one holder
 *  - has `holderids:id-222` column tracking another holder
 *  - has similar wide columns per holder for other details under the `holderdetails` column family
 *
 * and then one key per requester sorted by priority, like
 *
 * `req#deadbeef#e:123#q:some-queue-name#s:20#10#2024-01-10T10:10:10.000Z#id-333`
 *   - fixed metadata columns for `connectionName`, `recordedAt`, etc.
 * `req#deadbeef#e:123#q:some-queue-name#s:20#20#2024-01-10T10:10:20.000Z#id-555`
 *   - same fixed metadata columns
 * `req#deadbeef#e:123#q:some-queue-name#s:20#10#2024-01-10T10:10:30.000Z#id-444`
 *   - same fixed metadata columns, lower priority so sorted later in the keyspace
 */