📝 Scaling Writes While Designing Systems

Most engineers don’t know how to scale writes, because writing everything to one single database instance may have worked for your small company but won’t cut it in a big-tech interview.

Here are the 𝟰 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 one 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗸𝗻𝗼𝘄 𝘁𝗼 𝘀𝗰𝗮𝗹𝗲 𝘄𝗿𝗶𝘁𝗲𝘀 𝗶𝗻 𝗮𝗻 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄:

1️⃣ 𝗩𝗲𝗿𝘁𝗶𝗰𝗮𝗹 𝗦𝗰𝗮𝗹𝗶𝗻𝗴 & 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗖𝗵𝗼𝗶𝗰𝗲𝘀

You’re probably underestimating modern hardware. Bigger machines — 200 cores, 10Gb NICs, SSDs — can push write limits further than most expect. Consider write-optimized databases like Cassandra, time-series stores, or column databases also improve throughput, though usually at the cost of slower reads.

2️⃣ 𝗦𝗵𝗮𝗿𝗱𝗶𝗻𝗴 & 𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻𝗶𝗻𝗴

Spread the load. Hashing on userId or postId spreads writes evenly across shards. Vertical partitioning separates “post content” from “post metrics,” so counters update without blocking core content. In interviews, always explain your partition key choice as balanced distribution is key.

3️⃣ 𝗤𝘂𝗲𝘂𝗲𝘀 & 𝗟𝗼𝗮𝗱 𝗦𝗵𝗲𝗱𝗱𝗶𝗻𝗴

When you can afford it, queues like Kafka or SQS absorb bursts so databases process writes steadily, but they mask issues if overload is constant. Load shedding drops lower-value writes, such as redundant location updates, to preserve critical ones.

4️⃣ 𝗕𝗮𝘁𝗰𝗵𝗶𝗻𝗴 & 𝗛𝗶𝗲𝗿𝗮𝗿𝗰𝗵𝗶𝗰𝗮𝗹 𝗔𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻

Things work better in chunks. Batching collapses many writes into fewer operations, like turning 100 likes into one counter update. Hierarchical aggregation reduces volume further by processing locally before sending upstream. Both approaches ensure no single component is overwhelmed.

💡 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝘁𝗶𝗽: Don’t just say “shard the DB.” Show the tradeoffs: “For posts, I’d shard by userId to spread writes evenly. For engagement metrics, I’d batch and aggregate to reduce DB pressure.”

👉 𝗥𝘂𝗹𝗲 𝗼𝗳 𝘁𝗵𝘂𝗺𝗯:

• Exhaust hardware + DB tuning first
• Shard for steady load
• Queue or shed for bursts
• Batch & aggregate for extremes

Akhil Singh Chauhan

Creator