Interesting data model problems #2 - querying journal/transactional data
In these series of articles, I write about modelling problems that result in underestimates. You may also be interested in this post:
Consider the following Facebook news feed:
The feed represents a list of journal/transactional data stored against your database of some kind (it could be SQL, NoSQL or even just a bunch of files). I call this transactional data because it represents a data where there is a lot of activity. It is also loosely a journal, because data is usually added to the system, rather than being updated or deleted.
When estimating the effort of querying the data and rendering it on screen, we often forget that the user may also add new items to the list. In the instance above, the user is prompted to post "what's on your mind?". After posting a new item, this item should appear in the feed so that the user knows their action succeeded. However, frequently, the estimate only covers the query scenario, and not the refresh scenario.
Questions to ask:
- When user adds a new post, do we need to re-query the list? In particular, SPA applications may have decomposed the UI elements of new posts and list of posts into separate concerns and they will need to be wired up.
- Does the list represent a live query, when new data appears on the server, we need to notify the user to refresh or update their list?