I had an interesting issue come up at work last week. I got to have a discussion with my designer about how my persistence layer wouldn’t allow his design to work.

The scenario was pretty basic. We were making a task tracking system as part of a single page angular app. The UI looked something like this amazing rendition:

Tasks are ordered by date due, ascending. Not all tasks will appear at once, but clicking load more tasks will load another 10 tasks until there are no more. Hitting the add task brings up a dialog where a task is added. This is where our eventual consistency problem lies. Once that task is added, it should of course show up in the list. If it had a due date of say 11/15, then it wouldn’t show up on this screen, but the user would expect it to show up if the load more tasks button was pushed.

We have eventual consistency though. What that means is if the user adds the task, and then immediately pushes that ‘load more tasks’ button, the task may not yet be in the index, so it may not show up, even if it theoretically should.

So, the solution is easy right? Just append the task to the list from the client.

The problem is, where does it belong in the list? It might come in on the next click of the button, or it might not come in for three more clicks, depending on how many tasks are between 10/26 and 11/15. For all of the new loads until the task is either returned from the server, or added to the list from the client, we have to track on the client whether the task is in the list, and whether it SHOULD be in the list. Then we have to make the client side determination whether to add it.

This is a lot of business logic! I sent this one back to my designer to think about.

Many document database advocates downplay eventual consistency by saying things like ‘Of course your search results can be stale!’. You know what, that’s right, my search results CAN be stale, no big deal. However when I have a paged ordered list like this, staleness is a killer.