Prashant Kumar

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

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

API design is an important step in any system design interview. You'll need to be able to: 1. Choose the right "API protocol" ie. REST, GraphQL, RPC 2. Follow proper protocol semantics 3. Handle follow up questions about pagination, security, versioning, etc. I'll admit, my bias is that interviewers who are nit-picky here are focused on the wrong things. BUT, that being said, it's easy enough to get right if you know the rules of the game. We recently launched a new deep dive on API Design complete with a YouTube video to match! Let me know what you think :) Article: https://lnkd.in/gih4Wyp3 Video: https://lnkd.in/gy_QNvRG

181

6 Comments

The first SDE-2 absolutely nailed the system design round. The question was: Design a live streaming system. The second SDE-2 was asked to Design Google Drive. He did well, spoke about trade-offs, but missed one important detail: chunking the file, especially for large uploads. Yet, the second engineer got the job. These are from real interviews I took around 4 months ago. You might ask: Why? Only one reason, the second one nailed the behavioral questions like a boss. The question was about working on a project with tight timelines. The first SDE-2 (subtly) blamed the external team’s API for delays, which led to tight project deadlines. The second one, on the other hand, shared a story about how he helped his manager prioritize requirements to navigate the crunch. That’s how important behavioral interviews are. Yet, 90% of SDEs leave them to luck. If everything else is equal: - DSA (both solved the coding problems), - LLD (designed with solid object-oriented principles), - HLD (covered all the P0 functional and non-functional requirements) then your behavioral answers become the deciding factor. Yes, the second engineer missed the file chunking detail. But it wasn’t a critical red flag. He covered all other parts well and crushed the behavioral round. As long as you're working with humans (no matter how many), you’ll be judged on your behavioral skills. Call them soft skills, leadership skills, whatever you like, but you should prepare them well in advance. You can start preparing for behavioural interviews right away, with these 5 MUST read behavioural interview posts I wrote. (tip: save this post for later, as it may take some time to complete all of them) [1] How to answer any behavioural interview question https://lnkd.in/gH3N8b5q [2] 4 step guide for behavioural interview preparation in 3 hours https://lnkd.in/gccxG3MP [3] How to create 10+ stories for your past projects https://lnkd.in/g4nv_jqU [4] How to answer a failure story? https://lnkd.in/gtN-Dfuv [5] 10 behavioural interview mistakes to avoid at all cost https://lnkd.in/gpupvYVs If you’re preparing for mid-senior SDE or EM roles and need dedicated help with behavioral interview prep, DM me COACH.

135

23 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

Transactions are a protocol on top of a storage layer. It might be integrated into the storage layer. But you can also always build your own transaction layer on top of a storage layer that doesn't support transactions. You can also even ignore the transaction layer of any storage layer that has an integrated transaction layer and build your own transaction layer on top. Convex did this, reimplementing MVCC on top of Postgres (or MySQL or something). And the Delta Lake protocol for transactions on blob storage is even simpler.

83

4 Comments

Sharing the slides from our recent talk at #Current25 titled "Streaming Aggregations at Scale using Kafka and Kafka Streams". Thanks to everyone who attended. Grateful to see so many developers interested in building with Kafka Streams. Feel free to reach out to me/Shivam Y. for any doubts/follow-ups. For folks who would like a TLDR version, Confluent posted this excellent executive summary capturing the essence of the talk in the lead-up to the summit - When milliseconds matter, traditional databases struggle. At ShareChat, handling hundreds of thousands of counter updates per second led to hot-spotting issues, inconsistent data, and costly write volumes. The solution? Kafka & Kafka Streams. Happy Learning !!

124

1 Comment