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

While iterating keys, a user can create an iterator and seek to <queue_id, target_sequence_id> and iterate from there.

• 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.

As another way to solve the second problem, you can set an end key of your iterate when you iterate inside a queue_id, by letting point to <queue_id, max_int> <queue_id + 1>. We encourage you always set it no matter whether you see the slowness problem caused by deletions.

If you want to further optimize this use case, to avoid binary search of the whole LSM tree each time, consider using TailingIterator(or called in some parts of the codes) ().

The queue service is a good use case of CompactOnDeletionCollector, which prioritizes ranges with more deletes when scheduling compactions. Set ImmutableCFOptions::table_properties_collector_factories to the factory defined here: https://github.com/facebook/rocksdb/blob/master/include/rocksdb/utilities/table_properties_collectors.h#L23-L27