NoSQL PaaS databases like AWS DynamoDB or Cosmos DB offer incredible capabilities in scale, speed, and availability. There is also a dark side to those databases. They will punish anyone greatly for mistakes. And no mistakes are punished more than choosing the wrong partition key. Below is an ORDERED list on how to approach selecting the partition key.

I’ve seen multiple people struggling with trying to mock the ILogger calls. This post will hopefully save some people from wandering this path. Here it goes:

Here is why:

I will be back to the series about data modeling in noSQL databases, but for now, I want to note down a few arguments that are still hot after an interesting discussion with a friend. The talk boiled down to a simple question:

The problem of storing draft state and auditing is not limited to noSQL databases, and as previously, below patterns can be applied to SQL modeling. But because noSQL databases are, in most cases, lacking transactionality over multiple partitions, the problem is harder there. Making it more interesting :) Additionally, smart use of neet features of noSQL databases allows for a novel solution.

The problem(s):

Problem 1: Storing temporary state

Most developers cringe when they hear about storing temporary state, but can’t imagine living without Save as draft in Gmail, or git stash :) Give the users what You expect. A different few use-cases :

• The user can edit a document and save it as a draft. That draft can be later on committed or discarded.
• UI flow requires a page reload when working on a single object. I know that we have SPA applications now, but not everywhere and we might be switching between different systems, or refactoring a legacy system.
• Our document validation logic is quite complex, requires external HTTP calls, takes a long time to execute, and sometimes requires retries. Since we are good developers, we don’t run that logic during saving but save as draft, schedule a background task to do the validation. If something fails, we notify the user - a good UX.

Querying hierarchical data is always where the big boys of SQL shined. And I really mean the big boys part since only Oracle, and Microsoft SQL Server have support for CTE [As Thomas Levesque pointed out in the comments, not only those have support for CTE. Full list on wikipedia] (Common Table Expressions) that allow for executing one SQL statement what will fetch a subtree. There are data modeling approaches that allow for doing hierarchical data reads with noSQL databases and databases without support for CTE.