Never Lose a Battle due to Miscommunication

This edition of the newsletter contains

• one quick write-up that will help you grow faster 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.

---

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.

---

Never Lose a Battle due to Miscommunication

At your workplace, keep people informed. When driving a project or working on an individual item, you should always keep the people informed about progress, clarity, and timeline.

People typically want answers to three key questions

• Timeline: when will this be done? are we on track?

• Progress: what has been accomplished so far?

• Risks: what's still pending, and are there any blockers?

If you have a downstream consumer of your work, they would care about the usability and clarity of your interfaces. They need clear documentation and timelines to prioritize their work. Do your homework, build clarity, and always keep them informed by

1. drive weekly updates

2. drive daily updates for close collaborators

3. build a comfortable rhythm

This shows commitment and transparency. Never keep stakeholders or collaborators in the dark—it only breeds anxiety and mistrust.

So, with people you work closely with, never hesitate to ask questions, share updates, and make sure everyone feels comfortable sharing concerns or suggestions.

Never lose a battle due to miscommunication.

---

Here's the video I posted

I published a video - Implementing Distributed Transactions using Two-Phase Commit Protocol

To maintain atomicity and consistency across two services, we leverage distributed transactions, which are typically implemented using Two-Phase Commit.

While most of the resources discuss the theory, here’s a quick video of me explaining how to implement it and the code you’d write. I explained the details by taking the example of a 10-minute food delivery product.

It is a no-fluff video, give it a watch

---

Paper I read and would highly recommend

I spent some time reading On-the-fly Sharing for Streamed Aggregation

This weekend, I would recommend a paper talking about how aggregations work in a data stream. The paper is from Google titled "On-the-fly Sharing for Streamed Aggregation."

It is a challenge to efficiently process a large number of streaming aggregate queries with differing predicates and sliding windows in dynamic environments. The paper covers three methods

1. shared time slices (sts) for varying windows

2. shared data fragments (sdf) for varying predicates, and

3. shared data shards (sds) for queries with both varying windows and predicates.

This is a pretty awesome paper if you want to know how large-scale complex aggregations are made efficient by leveraging sharding, windowing, and on-the-fly query optimization. By reading this, you can always parallel and understand how our regular databases would execute things internally.

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 would recommend you to read.

• Hacking the Postgres wire protocol

• Query Engines: Push vs. Pull

• Frankenstein’s __init__

---

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.