No One Ships Great Software Alone

This edition of the newsletter contains

• a write-up to help you grow in your career
• a video I posted
• a paper I read

I have also shared 3 super-interesting articles to read over the weekend. Thank you once again for reading this edition of my Newsletter. Now, without further ado, let’s jump right in.

Btw, enrollments are open for my Systems Design October cohort (sessions start 11th Oct). If you'd like to dig deeper into systems, their implementation, and how to design them the way they actually run in production, check out:

arpitbhayani.me/course

The course is completely no-fluff and packed with brainstorming and discussions that will shape your thought process and intuition. You'll feel like you're part of a real technical discussion happening at your workplace.

No One Ships Great Software Alone

The best engineers ask for help early and often. We all have blind spots - technical, architectural, and just plain human. I've lost count of the number of times a teammate's quick input saved me hours of exploration, debugging, and a costly mistake in a couple of cases.

I believe reaching out isn't a weakness - it's how we move faster, build smarter, and grow together. When you ask someone for feedback, you're not just improving your work - you're building a bridge.

• you show respect for their experience
• you invite collaboration, not judgment
• you create shared ownership early
• you make it easier to call in help when things go sideways
• you remind everyone: we're in this together

Don't wait till you're stuck or blocked to involve others. Pull them in early. It makes the work better, and it makes you better to work with. Everyone's busy, but most people are happy to help - especially if you’ve already shown that you value their input.

Build trust before you need it.

By the way,

Being hands-on is the best way for you to learn. Practice interesting programming challenges like building your own BitTorrent client, Redis, DNS server, and even SQLite from scratch on CodeCrafters.

Sign up, and become a better engineer.

Here's a video from me

I published a video - An in-depth introduction to Canary Deployments

Canary deployment is all about deploying changes to one production server, and once everything looks good, the changes are rolled out to others. But why is it called Canary deployment?

The reason behind it is not at all related to computers, but it stems from mining. I have covered this and also the technical details around deployments in the Designing Microservices playlist. Give it a watch

Here's a paper I recently read

I spent some time reading ScaleDB: A Scalable, Asynchronous In-Memory Database

A point of contention for most in-memory databases is auxiliary structures like B-trees that handle range lookups.

Some time back, I read a 2023 paper titled "ScaleDB: A Scalable, Asynchronous In-Memory Database," which tackles this problem by decoupling range index management from transaction execution.

I was expecting a fancy solution to this problem, but after skimming the paper once, I was surprised to see a super simple solution - just delay range index updates.

The solution is all about a couple of hash tables called indexlets and phantomlets that buffer updates and hold metadata, which is then utilized to maintain consistency with async writes. The transaction commits without waiting on the index, and you still get serializability.

By the way, if you are into databases and data structures, you will certainly find this paper interesting; it is a solid read.

You can download this and other papers I recommend from my papershelf.

Three interesting articles I read

I read a few engineering blogs almost every day, and here are the three articles I read and would recommend you read.

• Protobuffers Are Wrong
• The Boring Future of GenAI
• The Math of Shuffling Cards

Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses

1. System Design Course for Beginners
2. System Design Course for SDE-2, SDE-3, and above
3. Redis Internals Course

I keep sharing no-fluff stuff across my socials, so if you resonate, do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.