The complicating factor in having a single index is in the first use case outlined just after the diagram. We’re using the date key as, what in the relational database world is called, a partial index. Walking that index shows us only new entries that we had not previously seen. Had we implemented this using a single index, we would be forced to have some way to mark an entry as new. Scanning for new entries would then degrade into a search requiring us to walk the whole index considering each entry. We’ve already seen that this doesn’t scale. Granted, there are some tricks that we can do to make such a search more efficient, but that brings the code base further away from our needs in our second use case.

After much consideration, I found this algorithm to be an acceptable compromise. I, of course, reserve the right to totally change my mind after we’ve seen this code perform in production…

I think if the initial part of the UID were time based, you could have only one indexing. Random UID generate an automatically balanced tree, but you have enough crashes, all around the world, that any 5 minute period is pretty well balanced too.