System Design Interview exposes readers to many concepts that they might otherwise not consider when designing systems. Unlike Designing Data Intensive Applications by Martin Kleppmann, System Design Interview does not provide a foundational first-principles understanding of *why* we can achieve performance improvements. There were two very notable examples of this (and many more I leave undiscussed):
1. At one point, in the Chat design discussion, the author recommends we use a key-value store like Cassandra over a conventional database, but does not provide the critical insight that key-value stores use SSTables which provide sparse, in-mem indices which can performantly support many more rows than on-disk b-trees for highly distributed/"partitioned" systems (also: fewer disk-seeks). This very key distinction of in-mem hash vs on-disk indexing is critical, but the author merely says it "scales better". In general, the author doesn't seem to provide users with a clear grasp of why some NoSQL databases are better than others for some applications, but instead sort of charges ahead with a particular implementation, which I find troubling.
2. The discussion of designing Youtube is clearly a copy of the Facebook whitepaper of how they built their distributed video upload service. However, the author fails to mention a critical detail that most thinking readers would consider, a detail which the Facebook white paper clearly addresses (how to avoid memory leaks/unpredictable uploading times with different-sized videos, by chunking/parallelizing them). It's almost as if he simply wrote the top points from the paper, without actually stopping to carefully think about the overall system.
That said, the links and concepts in System Design Interview are quite helpful, and you will almost certainly learn something you did not previously understand, especially if you pair it with Kleppmann's book and follow-up with reading the end-of-chapter references. The author does a workmanlike job of actually outlining how to orchestrate various systems together, highlighting many details that are easy to overlook. His last chapter on designing Google Drive is impressively thorough and included many factors I would not have otherwise considered.
I primarily recommend the book for its references, which alone are good enough to justify buying the book, which begs the question: why didn't he quote them directly in the book? God knows we engineers know how to copy-paste.