Puneet Patwari

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.

Two storage engines split the database world. B-tree (Postgres, MySQL, InnoDB): keeps data sorted in fixed pages, updates in place. Reads are cheap because the row is exactly where it should be. Writes cost more because keeping everything sorted means rewriting pages. LSM tree (Cassandra, RocksDB, ScyllaDB): never updates in place. It appends the new value and lets a background job clean up later. Writes are cheap and sequential. Reads cost more because your row might be spread across several files. You can optimize for cheap reads or cheap writes. Not both. Pick the one your traffic actually needs.

Your database picked a side before you wrote a single query. Every database on earth is either read-optimized or write-optimized. There is no third option. The one you chose is taxing every operation you run, and most engineers never learn which tax they're paying.

Postgres and Cassandra both store your data on the same kind of disk. Same rows, same bytes. But Postgres updates a row where it sits, and Cassandra never touches the old one. It just writes a new copy and moves on. Same hardware. Opposite behavior. Why?

@MandiengBot Fundamentally it will be same.

@system_monarch Do scaling approaches for Software’s or SAAS systems fundamentally different for AI systems? I noticed there’s a lot of resources online when it comes to scaling for typical software systems, But very little to none touching on AI systems

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.

@Bharata_India Well someday but not now..

@system_monarch Are you ever open to joining a startup if the opportunity seems challenging enough? I am aware at this stage money isnt the sole driver for you and obviously you would be getting equity..

@Renate0414 Hmmm I can. Let's see..

@system_monarch V Could you share Agent knowledge

@bygregorr True.

@system_monarch architecture docs always describe the happy path. every bug that actually hurt my users lived in a degraded state nobody drew a box for.

@WadeMealing Does anyone in this world have their shit together?

@system_monarch Mate, ive seen JIRA "assign to" autocomplete. You cant convince me you guys have your shit together.

@sarsjits Okay but it doesn't make a difference. Some things you do for community and some things you do for algorithm. I don't like it much as well but have to do it. Just like a lot of things in life.

@system_monarch I am all for content but please repeatedly using 12+ years of experience and Principal Engineer in every post should be avoided.

@JazonTWong Good for you. You are eligible to skip this post. 🙂

@system_monarch Funny. You should put this on linkedin. That's where the false bragging goes. Not hard to handle millions of requests, any of the cloud load balancers do that out of the box.

@pactechnologies Hi Milan, there are various concepts which helps in scaling. Definitely orchestration is important.

@system_monarch If you haven’t figured out how to scale without orchestration after 12 years, 25 days probably won’t be enough. That isn’t theory. That’s practice.

@impractialdev Hmm, I hear you.. Let me see when I get the time, I will update my website.

@system_monarch Can you please create a combined pdf of all these posts? Would be grateful if the information is easy to digest.

@suryanox7 Awesome, great list of concepts..

I think most database content stays at the SQL vs NoSQL or indexing 101 level. I'd love to see someone with your experience cover the decisions that actually matter in prod like schema evolution, partitioning, replication trade offs, consistency, query planning, storage engines, and why certain database choices worked or failed at scale. I recently moved into a Staff role and joined a team that is much closer to the database side after spending years in application teams and it has been an eye opening shift. There is an entire world of engineering beneath the application layer that does not get enough attention. Definitely excited to learn more and would love to see content from someone with your experience.

@suryanox7 Oh man. I thought everyone talks about databases 😅

@system_monarch Thanks for amazing series, Would love to see some content on databases from your end. No one talks about databases.

@imsatyam2611 It's concluded, please check my first reply, you'll find all the links there. Thanks for your support :)

@system_monarch Excited for this series

@tpbh108_dev It's concluded, please check my first reply, you'll find all the links there. Thanks for your support :)

@system_monarch Excited for the series sir

@aminnnn_09 Love to see your comment om every post. Kudos to you.

@system_monarch 💎 Mine, following you since a long, thanks for sharing this.

@amitk_abk Welcome

@system_monarch Thank you for sharing these concepts in depth and concisely! Much appreciated!!