One way to avoid getting overwhelmed when you are designing a system is to approach it with a structure/mental model. Here’s a simple one I follow…
Think of any system as having 2 separate paths: a read path and a write path. Your database or storage layer sits at the center, and each path has its own set of problems and its own toolkit to solve them.
The write path is about durability and throughput. You are almost always choosing from the same set of levers: a message queue to absorb bursts, write-ahead logging for durability, batching to reduce I/O, and async processing to keep the critical path thin.
The read path is about latency and scale. Again, a fixed toolkit - caching at various layers (CDN, app-level, query-level), read replicas to offload the primary, denormalizing or pre-computing expensive queries, and pagination or cursor-based traversal to avoid full scans.
Once you start seeing these as two separate concerns, you stop designing a system and start answering two smaller questions: what does the write path need? What does the read path need? Then you wire them together through storage.
This ‘framework’ (if I can call it that) is not just useful during discussions, but also helps you reason through production systems, especially when you are building an understanding, trying to optimize an existing flow, debugging latency spikes, or planning for scale.
Hope this helps.
btw, this and many such models are what I discuss in my system design cohort. The coming one is the April cohort that starts 28th of March, and ~16 seats are remaining. In case you are interested. It is completely no-fluff and filled with real-world designs, insights, and nuances.
arpitbhayani.me/course