You can simply encode it as , where queue_id is fixed length encoded and sequence_id is encoded as big endian.

Since the oldest items are deleted, there can be a large amount of "tombstones" in the beginning of each queue_id. As a result, the two query might be exceptionally slow:

• While you are in the last sequence ID of a queue_id and try to call Next()To mitigate a problem, you can remember the first and last sequence ID of each queue_id, and never iterate over the range.

If a user finishes processing the last sequence_id of a queue_id, and keep polling new item to be created, just Seek() and call Next() and see whether the next key is still for the same <queue_id>. Make sure ReadOptions.iterate_upper_bound points to <queue_id + 1> to avoid slowness for the item deletion problem.

The queue service is a good use case of CompactOnDeletionCollector, which prioritize ranges with more deletes when scheduling compactions. Set ImmutableCFOptions::table_properties_collector_factories to the factory defined here: