I read the story a while ago and was waiting for the criticism in the comments. Now one comment [0] already pointed out many of the issues of the article. What

I read the story a while ago and was waiting for the criticism in the comments. Now one comment [0] already pointed out many of the issues of the article. What's been mentioned in other comments but not explained in great detail is the database design, so I want to expand that: The right way (TM) to do databases is to design a solid schema to keep data integrity and then apply indices and caches depending on your application needs. To be honest his application seems super simple to cache top-down, so a few lines inside the nginx config (which seems to scare him for some reason) would probably do. But if you use a real database (also TM) you can go bottom up, too: 1. solid schema with constraints 2. indices depending on your application 3. stored procedures, database views 4. some non-relational cache like MongoDB to cache denormalized data 5. maybe something in memory 6. (application) 7. nginx caching He started with 4. What he did is not a solid database design to brag about, instead he hardcoded a cache inside his application. If he wants to scale his application vertically or horizontally he will have big problems, because he misses a point at the beginning which contains the truth on which everything else is build upon. If he starts scaling up and then wants to change his schema he is basically in hell. What he did is nothing bad. It is exactly "the MVP way". MVP is not about slow or buggy software but a really small feature set and applying YAGNI. MVP is nothing bad, he seems to have great sucess with it! What I am criticising is not how he build his software but what he wrote about it, comparing it to a much harder case and thinking it has something to do with good design. [0]: https://news.ycombinator.com/item?id=12135748 https://news.ycombinator.com/item?id=12135748