If you are trying to understand distributed systems, focus less on what and more on why, when, and how. Answering what a system does is usually the easy part. The harder one is why it behaves the way it does.
This is actually learnable, and it comes from building intuition around trade-offs and from spending hours working through that one strange bug.
And that intuition is what really matters when things break. In those moments, surface-level or theoretical knowledge is not enough. What matters is having that ability to reason from ‘first principles’ and apply deep practical understanding.
For example, imagine a system where requests suddenly start timing out after a new deployment. Logs look normal, dashboards seem fine, and nothing obvious is broken.
If you only know what the system does, you are stuck.
But if you understand why it behaves the way it does, you start asking better questions - did latency increase due to a hidden network hop, did retries amplify load, did a small configuration change trigger cascading failures? That is where real debugging begins.
So, when you are picking up distributed systems, spend more time asking why, when, and how.
Hope this helps.