I'm currently designing an application, which will use a no-SQL database like MongoDB as the database. The database design will be fairly simple (CRUD).
According to the design, there will be a lot of reads, and someone suggests that I should add a cache layer for the database. I wonder if that's really needed for MVP? What level of effort would it be?
I think the best way to figure this out is to do some testing, which I will, but in the meantime, any opinions?
I haven't don't have any personal concrete experience in Redis caches - but your idea to test first, and see if it's actually an issue, is really good.
Consider doing a "volume and capacity planning" exercise, where you:
Make sure you take into account peaks in activity - e.g. "monthly sales", "Monday morning first logins" or whatever.
Then try and do some realistic performance tests based on your forecast. You should soon see how the actual performance stacks-up against the forecast. This should be enough to inform you if / when a cache is necessary.
Depending on how you do the performance testing, you may even discover that the performance bottleneck (if one exists) is not data access related (cache would not have helped); that's not necessarily likely, but stranger things have happened.
In terms of effort, I can't say. Kicking off a proof-of-concept on the side might be a good idea, so that you have made some progress before it becomes an issue.
I don't know what technology you are using, or what your architecture is, but using dependency inversion will help you to switch data providers with minimal / no impact to the layers of code above them.
If moving towards using a cache, familiarize yourself with caching design patterns, such as write-behind and write-through.
