Principal @Atlassian | Helping engineers reach Staff/Principal | 1:1 Mentorship & Mock Interviews | 90+ System design fundamentals - https://xitter.cf/t.co/Ots2nRhO5f

Hyderabad
Joined December 2025
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.
34
109
2
1,383
133,480
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.
2
2
13
1,230
“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.
1
9
1,811
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.
2
16
2,109
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.
15
1,612
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?
20
18
2
389
113,000
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
5
2,004
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.
8
34
4
441
18,861
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.
3
23
2,171
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.
21
67
1
489
19,370
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?
7
4
67
7,219
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.
1
1
12
939
A junior ships a working service with AI. Good. Now ask: What happens if it crashes after writing to the database but before acknowledging the message? Building faster is progress. Explaining failure is engineering.
1
2
24
1,960
The stakes have never been higher to go back and be a student. That's why you should study the fundamentals that will still matter after the next model launch. For backend engineers, that's distributed systems. I wrote it all down as a free 23-part series, in the order I'd learn it:
1
9
64
5,903
1. Load Balancing: why "balanced" traffic can still melt one server 2. CDN: how most of your traffic gets served before it reaches your origin 3. Caching: the five layers, and Redis is only one of them 4. Cache Invalidation: knowing when to throw data away 5. Rate Limiting: the day our own batch job became our worst traffic spike 6. API Gateway: the front door and the six jobs it does 7. CAP Theorem: the choice you make the moment the network splits 8. Sharding: the hardest scaling decision to reverse 9. Replication: why a user can see their own stale data 10. Partitioning: the cheap step most teams skip before sharding 11. Queues: turning traffic spikes into a steady stream 12. Microservices: why Prime Video saved 90% by moving off them 13. Microservices vs Monoliths: how Shopify and Stack Overflow scale a monolith 14. Fault Tolerance: timeouts, circuit breakers, bulkheads and retries 15. Database Scaling: the five steps, in the right order 16. Service Discovery: finding service X when every instance keeps moving 17. Consistency Models: the five models that separate a bank from a fraud incident 18. Eventual Consistency: patterns that make stale reads survivable 19. Distributed Transactions: two-phase commit vs Sagas 20. Leader Election: Raft, split-brain and fencing 21. Horizontal vs Vertical Scaling: bigger machine or more machines 22. Back of the Envelope Estimation: the five-minute maths habit 23. Idempotency & Data Locality: what makes retries safe All 23 parts are here: puneetpatwari.in/blogs/serie…
2
3
14
1,085
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
3
678
Major green flags in a Senior engineer: 1/ asks "what problem are we solving?" before "which tool?" 2/ rolls back first, debugs second 3/ writes the runbook nobody asked for 4/ says "I don't know yet" without losing the room 5/ deletes more code than they add some weeks 6/ explains trade-offs without making anyone feel stupid 7/ reviews PRs like they'll be on-call for them 8/ makes the juniors around them better 9/ estimates before building 10/ owns the outage, shares the credit
8
27
522
27,560
The most important quote from this blog is "the goal isn't a 10x builder. The goal is a 10x team". I love the contrasting take and support it as well. Thanks @sherifmansour for sharing this..
A few months ago, I published my thoughts on what we've learnt form hiring juniors in the world of AI: sherifmansour.medium.com/on-… Last week, Anthropic published a piece on “How employment is changing at Anthropic”: anthropic.com/research/emplo… Firstly, thank you again to the folks at Anthropic for continuing to share what they’re learning with the rest of the world. I found their post incredibly thought provoking and made me challenge some of my assumptions. I felt like one question folks could have from Anthropic’s findings is what does a junior add once the team is already AI native? My answer is that the learning curve keeps resetting. Each new wave of tools and techniques can ask experienced people to unlearn something; newcomers get to start there. In my time spent working in tech (old man here 🤣), unlearning has been one of the hardest things I’ve seen a workforce have to do - especially when the old ways made people successful. As an example, an experienced developer might ask how AI fits their workflow. Someone learning today might ask what workflow makes sense now that AI can write code. I’m not suggesting that means younger people always adapt better (although, I think that could be generally true). But their contribution doesn’t disappear once everyone has adopted today’s tools. Tomorrow’s approaches can create that opportunity again - I think of it more as a never-ending cycle. I think the challenge that will always exist is that newcomers help the team discover different ways of working, while experienced colleagues help them develop judgment and independence. That takes deliberate investment. So I’d still resist a blanket decision to stop hiring juniors. Instead, look at what the situation you’re in. Today, the vast majority of the world is unlearning how they used to work, the argument that once we’re all AI native you won’t need juniors doesn’t check for me - because tomorrow’s approaches for what “AI native” means will continually reset that assumption.
1
1
5
1,549
The dangerous AI answer is not the obviously wrong one. It is the correct-looking answer that quietly assumes: - retries are safe - clocks agree - messages arrive once - the network is reliable Senior engineers are paid to notice hidden assumptions.
3
1
18
1,893