Ravindra Divi

It was 8:42 PM at the Amazon office when Priya, a senior engineer, noticed a Slack message from Raj, the newest backend SDE on her team. “Hi Priya, the orders API endpoint you own is suddenly returning 503s after my changes. Could you help me debug? Sorry for the late message.” Priya hesitated for a second. She’d spent months refining that endpoint, handling edge cases, scaling for Prime Day traffic, even documenting the entire flow for new team members. She remembered her own early days, when breaking something felt terrifying, and the seniors weren’t always patient. For a split second, Priya wanted to reply, “It was working fine earlier. Did you check the wiki?” But she didn’t. She joined the call. Raj was clearly stressed, walking through his recent commits. First month at Amazon, production issue, and it was late. Priya listened, asked focused questions, and together they tracked down a missing API key in the environment config. Raj sighed, “Thank you, Priya. Didn’t mean to break anything, just trying to add new promo logic.” Priya replied, “No worries. Bugs happen to all of us. What matters is catching them fast. I’d always rather have a teammate who asks for help than one who hides a problem.” The next morning, Priya shared a quick note in the team channel: > “Thanks to Raj for surfacing the issue quickly and collaborating on the fix. These things happen, what counts is how we respond.” And as she updated her notes, Priya reflected: → Being smart is good but being reliable, calm, and collaborative under pressure is what builds trust. → The most critical projects rarely go to the “lone genius.” They go to the person the team can depend on, day after day. Over time, more teammates started coming to Priya for tricky launches, because she was steady, approachable, and always showed up when it mattered. Because in the long run, that’s what makes you the engineer everyone trusts to deliver. And that’s the reputation that really opens doors.

4,001

102 Comments

35 practical thoughts on system design Core Principles 1. Every system is a trade-off -> you never get speed, cost, and simplicity all at once. 2. Latency compounds -> every millisecond added across layers adds up to user pain. 3. Scalability ≠ performance -> one handles growth, the other handles speed. 4. Read vs. write paths -> scaling each requires completely different strategies. 5. Design for change, not perfection -> requirements will shift. Databases & Storage 6. Indexes are levers -> high-selectivity columns are worth indexing, low ones often aren’t. 7. Replication helps reads, partitioning helps writes -> don’t confuse the two. 8. Dual writes are a lie -> without coordination, you will see drift. 9. Event stores > queues (sometimes) -> better traceability, worse simplicity. 10. Cache invalidation is still the hardest problem -> freshness vs. performance is the eternal fight. Reliability & Consistency 11. Idempotency saves you -> retries without it will hurt. 12. Fail fast, fail loud -> silent failures sink systems. 13. Eventual consistency is a feature -> not a bug, but only if the business allows it. 14. Conflict resolution in active-active is business logic, not infra. 15. Durability isn’t free -> syncing across regions has cost and latency. Architecture Patterns 16. Microservices are an org structure, not a tech goal. 17. Monolith first, modular second, microservices last -> don’t jump too early. 18. Choreography scales, orchestration simplifies -> pick based on team maturity. 19. Serverless buys you focus, costs you control. 20. Queues don’t remove work, they smooth it. Observability & Operations 21. Tracing > logging -> logs tell you “what”, traces tell you “why”. 22. Metrics rot without ownership -> measure what someone actually uses. 23. Retries without backoff = DDoS on yourself. 24. Dead-letter queues aren’t optional -> every system has poison messages. 25. Levers > knobs -> design quick kill switches and controls to contain blast radius. Performance & Cost 26. Optimize the hot path, not the cold path. 27. Most bottlenecks live in the database, not the code. 28. Horizontal scaling beats vertical scaling ->until coordination kills it. 29. Warm caches mask bad queries -> measure against cold starts too. 30. The cheapest resource is disk, the most expensive is time. People & Process 31. The best architecture dies without documentation. 32. System design reviews aren’t about diagrams, they’re about trade-offs. 33. Small PRs are for speed, big PRs are for context -> balance both. 34. A senior engineer’s role in design is asking the uncomfortable “what if”. 35. No design survives first contact with production -> but good ones bend instead of break. Want to sharpen your instincts with daily practice? Check out joinenginuity.com One system design question every day, with streaks, badges, and leaderboards, and a dashboard to keep you sharp. Enjoy the rabbit hole!

1,462

93 Comments

Amazon Layoffs Incoming — And This Time, It's Principal Engineers Rumors[1] are circulating that Amazon is preparing another round of layoffs — and what's especially striking is that principal engineers are among those being targeted. This is a sharp reminder that: - Being senior doesn't make you immune to layoffs - As you climb the eng ladder (which is just another term for the corp ladder), you have to sustain your performance/impact, so cruising is not an option compared to common beliefs - Companies are entities that try to maximize revenue/profits – being laid off sucks, especially if you're on parental leave (or any kind of leave), on a precarious visa situation etc. I think we have seen enough layoffs in tech companies that these are probably the new normal. Companies who struggle to fire people through a regular process, will rely on layoffs to occasionally clean house. This sucks.

504

37 Comments

AWS Lambda is one of those technologies that looks perfect for almost everything. Take a notification service: "Event-driven by nature" "Scales effortlessly" "Pay only when used" On paper, Lambda feels like the obvious choice. But here’s the trap: if the Lambda is cold, the alert goes out seconds late. - A payment failure notification delayed by 3 seconds frustrates customers. - A security alert delayed by 3 seconds undermines trust. That’s the cold start problem. The good news: AWS has solutions today: 1. Provisioned Concurrency keeps functions pre-warmed. 2. SnapStart snapshots initialized runtimes for instant startup. Don’t just ask “Can I put this on Lambda?” Ask “What happens when it’s cold?” Wisdom in engineering often comes from knowing not just what a tool can do, but when it silently breaks your guarantees.

605

90 Comments

Here is the list of system design building blocks that are important irrespective of whether you are designing a system or preparing for a system design interview ✔️ Distributed message queue: A producer puts a message Or work in a line, which the consumers pick up for further processing or work defined. This is an important concept to explain how you can scale your system, perform asynchronous processing, ✔️ DNS: Translates website names to IP address. DNS service works much like a phone directory. Services like Route53 help configure the domain and routing, and one needs to understand common types of resource records like A, CNAME, NS, MX, etc. ✔️ CDN: The content delivery network is a server between the origin and the client. It stores and delivers content to the end users, reducing latency and improving the system's overall performance. ✔️ PUB SUB: Publish-subscribe messaging works asynchronously, involving publishers, topics, subscribers, and messages. It helps to decouple the system, scalability, Durability, etc. ✔️ Load Balancer: Load balancer helps divide and divert traffic across the system. It helps drive the overall system Availability and Performance. ✔️ Distributed Caching: Caching servers store the data in memory and return it to the end users, improving the overall performance and end-user experience. A fleet of servers works together to keep and serve the data in a distributed caching system, enhancing availability. ✔️ Database: Understanding data storage, storage, types, and choosing a Database, RDMBS Vs Nosql, is vital when designing a system. It is essential to deeply understand for what requirements RDBMS is the right fit, and nosql is the right fit. ✔️ Observability: It's important to know what is happening in the system. How do we make the system easier to debug and fix? Observability helps the system to drive maintainability, resiliency, and reliability. ✔️ Task Scheduler: This is an essential component that helps one decide how the tasks must be prioritized, delegated and how much resources need to be allocated ✔️ Unstructured Data Storage: Storing photos, videos, audio, and other unstructured data is essential when designing a system since these cannot be stored in traditional databases. One needs to create a highly available, consistent, reliable solution. and efficient ✔️ Scaling Services: Scalability is an essential building block of any robust system. Understanding various scaling options and what options should be used is critical. From Serverless to ID generators, one must understand the multiple options and how to design them. ✔️ Distributed Search: Search is the core of many system designs. Understating how to build a search system and the core building blocks of a search system, including crawling and indexing, is essential. #engineering #systemdesign #interview #productdevelopment

208

48 Comments

Is CDN a reverse proxy, just like a load balancer or an API gateway? Yes. While LB and API gateway fit the classic definition of a Reverse Proxy, CDN is also a reverse proxy with caching as its primary purpose. Like any other reverse proxy, 1. CDN acts as a single point of entry for client requests, 2. CDN abstracts out different origins configured behind it 3. CDN can also route the requests across multiple origins depending on the route-matching configuration. Hence, the deduction is on point, and LB, API Gateway, and CDN are all examples of Reverse Proxies. I elaborated on CDN, as it is an unconventional example. ps: I love how the comments on my YouTube videos are also no-fluff and filled with thought-provoking questions. Thank you for asking such great questions. By the way, the question was asked in my recent video on Forward and Reverse Proxy. In the video, I went into highly practical details with real-world examples and stories from my life. give it a watch and subscribe - youtu.be/HrG0MHkSsCA btw, enrollments open for sys design June cohort, about 30 seats left - arpitbhayani.me/course

324

8 Comments

If you want to become better at system design rounds, definitely read these 10 case studies by Neo Kim. I am 100% sure, they will make you smarter for your next interview.  1/ How Meta Achieves 99.99999999% Cache Consistency: → https://lnkd.in/e88kUZAm 2/ How Uber Computes ETA at Half a Million Requests per Second: → https://lnkd.in/eVKV2ePC 3/ How PayPal Was Able to Support a Billion Transactions per Day With Only 8 Virtual Machines: → https://lnkd.in/eqcb7MpP 4/ How YouTube Was Able to Support 2.49 Billion Users With MySQL: → https://lnkd.in/efmJw4Dx 5/ How WhatsApp Was Able to Support 50 Billion Messages a Day With Only 32 Engineers: → https://lnkd.in/gRqBgXfc 6/ How Uber Finds Nearby Drivers at 1 Million Requests per Second: → https://lnkd.in/eeqH9Hjh 7/ How Stripe Prevents Double Payment Using Idempotent API: → https://lnkd.in/erMkqwq4 8/ How Google Ads Was Able to Support 4.77 Billion Users With a SQL Database: → https://lnkd.in/efnSvwJp 9/ How Amazon S3 Achieves 99.999999999% Durability: → https://lnkd.in/eutGiK35 10/ How Slack Works: → https://lnkd.in/eATMDjrK

683

31 Comments

System Design #Day5 CAP Theorem says a distributed system can ensure only two out of three: - Consistency – All nodes have the same data - Availability – Every request gets a response - Partition Tolerance – System works even if some nodes can’t communicate

21

1 Comment