It's Not Enough to be Right; Learn to be Heard

This edition of the newsletter contains

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

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.

It's Not Enough to be Right; Learn to be Heard

Once you're in the system and thinking deeply, you'll start to notice inefficiencies and gaps. You might see decisions being made that feel wrong. But instead of putting your point across bluntly, it's important to raise it thoughtfully.

What I've learned over the last decade is that tone often matters more than the content, at least at first. Challenge decisions, yes, but do it with kindness and clarity.

Don't assume others missed something; assume they had different inputs. Frame your suggestions as additions, not corrections. It changes how they're received.

When offering feedback or questioning a choice, be mild in tone but sharp in your reasoning. That sharpness must come from preparation; your suggestions should rest on data, not vibes. Here’s what “doing your homework” looks like:

• understand the context and constraints
• explore alternatives and their trade-offs
• anticipate counter-arguments and prepare responses
• cite metrics, issues, or past incidents
• keep it brief but loaded with substance
• state assumptions and ask clarifying questions
• tie your suggestion back to team or product goals

This detailing builds trust. Over time, your feedback won't just be heard, it'll be sought. You'll be known as someone who elevates discussions, not derails them.

The goal isn't to "win" arguments; it's to move the team forward, together.

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 - How to Implement Vertical Sharding

Vertical sharding is feasible, but how can it be effectively implemented?

In vertical sharding, we distribute the tables across multiple database servers. For example, keeping all the payment-related tables in one database server, and all the auth-related tables in another.

In this video, we take an in-depth look, not at the theoretical side of vertical sharding, but at the implementation side of it. We will see how Vertical Sharding is implemented with minimal downtime and what the exact steps are to do it.

Here's a paper I recently read

I spent some time reading Web-scale extraction of structured data

The web is unstructured, and the value lies in extracting the implicit structure, indexing it, and making it a web-scale knowledge base.

Some time back, I read a 2008 paper from Google talking about how they extracted structured data from this unstructured mess, as free text, HTML tables, and deep-web (not dark) databases hidden behind forms.

The paper talks about multiple systems - TextRunner, WebTables, and the Deep-Web surfacing engine.

TextRunner processes and extracts information from unstructured text. It doesn't start with schemas; it discovers relations on the fly, purely from frequency patterns. WebTables processes HTML tables and makes them indexable.

The deep-web surfacer learns minimal sets of useful form submissions to process and fetch large hidden databases without consuming too much of the crawler resources.

If you like information extraction or large-scale search infrastructure, this paper will ground you in what it takes to operate at the full scale of the Web.

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.

• Images over DNS
• Boring is good
• What Makes System Calls Expensive

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.