Data is considered one of the most critical assets of any business, and that is why you have to invest a considerable amount of time in figuring out the best approach for dealing with it.
Nowadays, we have many options when it comes to choosing our approach to data. In the last few years, many kinds of databases and data storage have been created, including the following:
- File cloud storage
- Relational databases
- Document-oriented databases
- Real-time databases
- Graph databases
- In-memory databases
Your choice should depend on the problem that you're solving, and not on the option used by influential online companies, such as Facebook, Google, and Amazon.
Remember that different business requirements require different methods of approach.
You may now be wondering what kind of data storage you should choose. The most common answer to that question is that it depends on the context.
However, a dependence on the context may not be the ideal answer here, as it does not provide you with much guidance. With this in mind, the best advice that can be given is to try to make as many analogies as you can, in order to figure out the best data storage method for you. One consideration to bear in mind is this: don't get scared because of the eventual consistency inherent in NoSQL databases. I have seen a lot of people get rid of this kind of database for that reason. You have to understand that eventual consistency is not a technical concern at all, but a business one. Let me explain why.
Considering the example presented in Chapter 1, Software Architecture Today, assume that you have been tasked with implementing a new feature in a system with the following description:
Notice that this requirement doesn't follow the standard user story format:
However, the requirements are easy to understand and implement for the team in charge of working on them. For that reason, I mentioned earlier that even if you're still working with use cases or user stories, the matter of business requirements is the most important aspect.
An example of where eventual consistency is not a big deal is with the ordering of Facebook posts, in which each post is timestamped. Here, when a person adds a comment to a post, they think that they are seeing the last comment above theirs, but a few seconds later, they see that other comments did, indeed, get added before their comment. When this happens, it can be confusing. However, not imposing atomicity requirements on the comment order allows Facebook to scale the database globally, covering millions of posts per second. In contrast, it is important that a money transferring transaction require atomic transactions, in order to maintain consistency and avoid fraud or wasting money.
In summary, you first have to understand the business requirement that you want to accomplish, make as many analogies as you can with the options available on the market, and then, make your choice from those options. Once your decision has been made, it's always worth counting on frameworks that will allow you to interact with the data storage of your choice. Fortunately, Spring Data supports a bunch of data storage options. We will discuss the benefits of using this Spring project in the next chapter.