Bifalgorithm post

How will you scale the database if your database is struggling with massive load from users? Would you replicate the database, or will you use sharding? To solve this interview problem, you should know that sharding and replication solves two completely different problems. Replication means we have more copies of the same database. We have one primary database and multiple replicas, and these replicas are exact copies of primary database. Sharding is the opposite. You don't have copies here. You actually split the database into multiple smaller databases. called shards. Some users live on shard 0, some on shard 1, and so on. And no single database machine holds all the data. Now, replication helps you in scaling the read operation. The read queries from users get spread across all three replicas, and if the primary dies, a replica gets promoted and your app keeps running. But replication does nothing for database writes, because every write still goes to this primary database. Sharding actually helps in because four shards means four machines can now take the writes. Now, when the interviewer says the database is under load, then we have to ask one question. Is the database load due to a lot of read operations or write operations? If your application is read-heavy app, like Instagram, where users read hundreds of photos and write almost nothing, then you can simply go with caching and replicas. If database writes is the bottleneck due to one primary database, or your data has gone too big to fit on one machine, then you should go with sharding. A senior engineer always avoids sharding as much as possible, because techniques such as replication and caching are much easier to implement and reversible. For example, Figma only went to real sharding when single tables hit several terabytes. And in production environments, it is never about sharding versus replication. We use both of them together. Every shard is still one machine that can break, so every shard gets its own replicas.

How will you scale the database if your database is struggling with massive load from users? Would you replicate the database, or will you use sharding? To sol…

Ideas in this flowchart

  • Database Scaling Strategies
  • Replication
  • Multiple Copies
  • Primary and Replicas
  • Read Scaling
  • Sharding
  • Database Split
  • Write Scaling
  • Database Load Question
  • Read-Heavy Application
  • Use Caching and Replicas
  • Write Bottleneck
  • Use Sharding
  • Avoid Sharding
  • Combined Approach
Feed/

How will you scale the database if your database is struggling with massive load from users? Would you replicate the database, or will you use sharding? To solve this interview problem, you should know that sharding and replication solves two completely different problems. Replication means we have more copies of the same database. We have one primary database and multiple replicas, and these replicas are exact copies of primary database. Sharding is the opposite. You don't have copies here. You actually split the database into multiple smaller databases. called shards. Some users live on shard 0, some on shard 1, and so on. And no single database machine holds all the data. Now, replication helps you in scaling the read operation. The read queries from users get spread across all three replicas, and if the primary dies, a replica gets promoted and your app keeps running. But replication does nothing for database writes, because every write still goes to this primary database. Sharding actually helps in because four shards means four machines can now take the writes. Now, when the interviewer says the database is under load, then we have to ask one question. Is the database load due to a lot of read operations or write operations? If your application is read-heavy app, like Instagram, where users read hundreds of photos and write almost nothing, then you can simply go with caching and replicas. If database writes is the bottleneck due to one primary database, or your data has gone too big to fit on one machine, then you should go with sharding. A senior engineer always avoids sharding as much as possible, because techniques such as replication and caching are much easier to implement and reversible. For example, Figma only went to real sharding when single tables hit several terabytes. And in production environments, it is never about sharding versus replication. We use both of them together. Every shard is still one machine that can break, so every shard gets its own replicas.

"How will you scale the database if your database is struggling with massive load from users?"

👍
0
0 comments0 shares

Sign in to view and post comments.