title: Cursor based pagination timestamp
body: <p>I have to implement cursor-based pagination and am a bit confused on how to go about this given that the primary key of my entities is not an auto-increment, like for example Aerospike.  </p>
  
  <p>The most obvious alternative when comparison operator isn't available on the primary key in a distributed system where we don't use auto-increments, would be the use of a timestamp. But how reliable is this?  </p>
  
  <p>That is, two users may make an upload at exactly the same time, which basically screws up the logic behind cursor based pagination.<br>
  For example, give me the next 10 items as from a certain timestamp that was sent as cursor for fetching the next results. When this timestamp has two posts, 1 post may be dropped and neglected if it didn't fit in the previous requested count range (e.g. 10 posts of which the duplicate post would be at location 11).  </p>
  
  <p>How do you circumvent this problem?<br>
  The most obvious way would be to have a secondary field next to a timestamp with additional counter when a timestamp already exists, and handle the additional logic at application level, but all of this seems to add a lot of bloat.  </p>
  
  <p>Any insight highly appreciated! </p>