At Amazon, a strong L5 with 7 to 8 years of experience can cross ₹1 Cr+ CTC. At L6, compensation can go well beyond ₹1.5 Cr+ depending on team, location, stock, and level. But the interesting part is not just the money. Look at why recruiters reach out for these roles. It is because their background shows they understand hard systems, and they have enough proof of work that people can see it. Today I am a Principal Engineer, but if I were starting in distributed systems from scratch and wanted to turn that skill into career leverage, this is exactly how I would do it. [1] Build the fundamentals before touching big scale I would first get comfortable with the building blocks: → networking and request lifecycle → databases, indexes, transactions → caching → queues and async processing → replication → sharding → consistency → retries, idempotency, backpressure → observability and failure handling Basically, have the understanding to see what happens when one normal backend service gets slower, busier, or partially unavailable. [2] Build systems where the tradeoffs come into the picture. Do not only watch architecture videos. Build things. Start with: → URL shortener → rate limiter → notification service → job scheduler → file upload system → search service → payment workflow Then deliberately make them harder. – What happens at 10x traffic?” – What if Redis dies?” – What if the same event arrives twice?” – What if one shard becomes hot?” [3] Read engineering blogs and reverse-engineer decisions Uber, Netflix, Stripe, Discord, Cloudflare, LinkedIn, Meta, Amazon. There’s golden material out there. While reading, ask yourself: – Why did they choose this? – What was breaking before? – What tradeoff did they accept? – What new problem did their solution create? That is how engineers actually learn architecture. [4] Put your thinking in public This part is massively underrated. Write about what you learn. Publish: → design breakdowns → architecture diagrams → GitHub projects → incident analyses → open-source contributions → performance experiments Build enough public proof that when someone searches your name, they can tell what kind of engineer you are. That is when learning starts compounding. You study distributed systems to become better at engineering. Then that knowledge helps you design better systems. Those systems give you better stories. Those stories become public proof. And eventually, opportunities start finding you instead of you constantly chasing them. That is the leverage.

Fabrice Bellard is the weirdest software engineer on Earth. > Wrote the video stack that powers YouTube, Netflix and TikTok. > Created the emulator that runs half the cloud. > Made a C compiler that compiles and boots Linux in 15 seconds. > Built a full PC that runs Linux inside your browser. > Wrote a JavaScript engine used in FIFA. > Set a world record calculating 2.7 trillion digits of pi on a cheap desktop. > Turned a VGA card into a TV transmitter. > Makes software 4G/5G base stations. > Invented a better-than-JPEG image format. > Built neural-net and LLM compressors that beat the official benchmarks. It’s like FFmpeg, QEMU, LLVM, V8, a math institute, Qualcomm, and a compression lab… All rolled into one guy who barely gives interviews. @ID_AA_Carmack has said Bellard is probably a better overall programmer than he is. That tracks. Truly a legend 🫡

90 LPA–1.4 Cr/year job requirements for an L5 Senior Role or Equivalent at FAANG+ companies: ↣ hardcore DSA ↣ strong system design ↣ full-stack development ↣ AWS or GCP proficiency ↣ experience writing design docs ↣ ability to design scalable services ↣ AI/ML with solid math (Role-based) ↣ comfort with microservices and APIs ↣ deep distributed systems knowledge ↣ strong debugging and production skills ↣ clean coding in Java, Python, Go or C++ ↣ strong grasp of Authz, also if the role requires ↣ familiarity with storage engines SQL, NoSQL ↣ strong grasp of security authn, authz, encryption ↣ ability to reason about latency, throughput & availability ↣ solid understanding of caches, queues, and load balancers ↣ driving through ambiguity and cross-team collaboration ↣ minimum 4-6 years high-impact engineering experience

Something I wish I knew when I started learning system design is that most systems follow the same exact patterns. The requirements change. The trade-offs change.  But you keep coming back to a familiar set of building blocks. Here are 25 that keep repeating themselves.