Principal @Atlassian | Helping engineers reach Staff/Principal | 1:1 Mentorship & Mock Interviews | 90+ System design fundamentals - https://nitter.cf/t.co/Ots2nRhO5f
Hyderabad
Joined December 2025
- Tweets2.4K
- Following126
- Followers25.6K
- Likes1.9K
Pinned Tweet
A month ago, I told everyone:
"I've been a backend Engineer for 12+ years. Today, I'm a Principal Engineer at Atlassian.
I've designed systems that handle millions of requests. Sat on both sides of system design interviews.
Reviewed more architecture docs than I can count.
Starting today, I'm breaking down the fundamentals of scaling for the next 25 days.
If you're learning system design bookmark this thread, you're going to get a lot of learning from this."
FYI, the series has concluded. Here are all the concepts, please bookmark, share, learn and the most important build from the learnings you get.
Also, if you have any ideas on what you'd like to see from me, please let me know, any other series or concepts to be broken down.
What system design rounds expect at each salary band in India:
₹20–35 LPA (SDE-2)
↣ design one service end to end
↣ APIs, schema, indexes, caching
↣ "Design a URL shortener"
₹35–60 LPA (Senior)
↣ scale it to 10x without falling over
↣ sharding, queues, replication, real numbers
↣ "Design WhatsApp message delivery"
₹60 LPA–1 Cr (Senior+ / Staff)
↣ trade-offs across many services
↣ consistency, migrations, cost, multi-region
↣ "Move payments to a new database with zero downtime"
₹1 Cr+ (Staff / Principal)
↣ what to build, what to cut, who owns what
↣ 5 teams shipping without breaking each other
↣ "Our cloud bill is ₹2 Cr a month. Cut it in half."
Every jump in pay is a jump from "build this" to "decide this."
Interviewer:
Why can't you just buy a server with 10 TB of RAM and keep your whole database in memory?
My career switches:
2013: TCS (after Microsoft rejected me)
2018: ThoughtWorks
2019: Freshworks
2022: Microsoft
2025: Atlassian, Principal Engineer
Five companies in 12 years, each switch for a harder problem than the last.
Compounding looks boring until year 10.
Netflix staff system design round:
Interviewer: "One of your 200 instances has a bad config. It returns a 500 error in 2ms for every request.
Your load balancer uses least-connections.
Within a minute, 40% of all traffic is going to the broken instance.
Why?"
Least-connections sends each request to the server with the fewest open connections.
A server that fails in 2ms closes every connection almost instantly. So it always looks like the least busy server in the fleet, and it keeps winning.
Fix: eject hosts on error rate (outlier detection), not just "is it alive", and slow-start new hosts.
Fast failures look exactly like a healthy, idle server to a load balancer.
Interviewer grilling you on CS fundamentals:
Your server has 40GB of free RAM.
CPU is at 8%.
It refuses every new connection with "Too many open files."
How?
Every socket is a file descriptor. Linux caps how many one process can hold (ulimit -n, often 1024 by default).
RAM has nothing to do with it.
Raise the limit, then find out why you hit it: connections nobody closes, sockets stuck in CLOSE_WAIT, a client that never sets a timeout.
The limit was the alarm. The leak is the bug.
Payments system design round.
How many of these can you explain clearly:
Idempotency keys
Double-entry ledger
Authorisation vs capture
Refunds vs reversals
Webhook retries and dedup
Reconciliation
Settlement cycles
Chargebacks
Exactly-once vs effectively-once
The outbox pattern
Holding money in a "pending" state
8 or more and you can walk into a fintech company's loop and do a decent job.
Almost every backend engineer in India ends up working with payments systems at some point. Learn this list before that day comes.
AI system design in 6 lines:
Slow answers → stream the response
Big bill → cache repeated questions
Hard questions → route to a bigger model
Wrong answers → better retrieval + evals
Runaway agent → step limit + kill switch
Provider outage → fallback model
System design round at OpenAI:
You switch to a model that's 5x cheaper per token. Same prompts. Same traffic.
The monthly bill goes up 30%.
What happened, and what should you have measured before switching?
Price per token was never your cost. Tokens per successful answer was.
The cheaper model:
→ writes longer answers
→ breaks your output format more often, so your code retries
→ gives weaker answers, so users hit "regenerate"
→ needs a longer prompt with more examples to behave
Measure cost per completed task before you switch. That's the number finance will ask you about on Monday.
A principal engineer may write less code than the strongest senior on the team.
But one decision can remove six months of unnecessary work, prevent an outage, or let three teams move independently.
Output is visible.
Avoided complexity usually is not.
“Which framework should I learn next?”
Before adding another one, answer these:
Why did your last service time out?
How does its data recover after a crash?
Which invariant must never break?
Frameworks change.
Failure modes keep interviewing you.
A design can be technically correct and still fail the team.
If only one engineer can deploy it, debug it, or explain its failure modes, you did not build a resilient system.
You built a dependency on one person.
instagram.com/reel/De3yrUStE…
Please hit me up on Instagram. 😃
Staff-level work is not doing the hardest ticket on every team.
It is finding one constraint that makes five teams slow, then removing it without creating a new dependency everyone must carry.
Leverage often looks boring from the outside.
System design round at BookMyShow for SDE-3 (₹70L+ CTC):
12:00 PM. Coldplay tickets go live. 8 lakh people are in the queue for 50,000 seats.
Two users tap seat F-14 in the same millisecond. Both see "Seat selected."
You can't lock the whole seat map on every click. If you lock nothing, one of them pays ₹6,500 for a seat someone else already owns.
How do you make sure every seat goes to exactly one person, without freezing the seat map for everyone else?
Btw, seat holds and idempotent payments come up in almost every Senior round.
I've written full answers to 93 questions like these in my System Design vault, and the one on idempotency is free to read: puneetpatwari.in
CANCEL your weekend plans.
You NEED to:
- Load test your side project until it breaks, then fix the first bottleneck
- Add tracing to one request and read every span
- Put your LLM call behind a timeout, a retry limit and a fallback model
- Rewrite one OFFSET query as keyset pagination
- Kill your database mid-request and watch what your app does
- Write the runbook you wished existed the last time prod went down
- Read one real postmortem end to end. Cloudflare, GitLab or AWS.
One weekend of this beats a month of tutorials.
If AI can produce a standard architecture diagram in seconds, interviews should care less about recall.
Change one constraint instead:
“The dependency is down, the retry is unsafe, and 1% of requests may be dropped. What do you protect?”
Judgment is harder to autocomplete.
If you learn backend engineering for AI, you will never be unemployed again.
Stage 1: LLM calls are backend calls
- Learn: tokens, streaming, timeouts, retries, structured outputs.
- Practice: wrap an LLM API with a timeout, retry limit, fallback model and a cost log per request.
Stage 2: Retrieval
- Learn: embeddings, chunking, hybrid search, reranking, metadata filters.
- Practice: RAG over real docs, with citations and a freshness filter.
Stage 3: Cost and latency
- Learn: prompt caching, semantic caching, model routing, batching.
- Practice: cut cost per query by 50% without dropping your eval score.
Stage 4: Agents in production
- Learn: tool calling, step budgets, idempotent tools, human approval.
- Practice: an agent that can issue a refund safely.
Stage 5: Evals and observability
- Learn: golden datasets, LLM-as-judge, tracing.
- Practice: an eval suite in CI that blocks a bad prompt change.
Btw, if you're preparing for system design interviews, I've put together an in-depth fundamentals guide.
You can check it out here: puneetpatwari.in