---
title: 'Sharding in System Design Interviews with a Meta Staff Engineer'
source: 'https://youtube.com/watch?v=L521gizea4s'
video_id: 'L521gizea4s'
date: 2026-08-04
duration_sec: 1834
---

# Sharding in System Design Interviews with a Meta Staff Engineer

> Source: [Sharding in System Design Interviews with a Meta Staff Engineer](https://youtube.com/watch?v=L521gizea4s)

## Summary

This video, presented by a former Meta staff engineer, provides a comprehensive guide to sharding in system design interviews. It covers the motivation for sharding, how to choose a shard key, various distribution strategies, common challenges like hotspots and cross-shard operations, and how to discuss sharding effectively in an interview context.

### Key Points

- **Introduction to Sharding** [00:01] — The video focuses on sharding, a core system design concept, covering what it is, how to choose shard keys, distribution strategies, and common challenges.
- **Motivation for Sharding** [00:29] — Sharding is needed when a single database (e.g., AWS RDS Postgres) hits its limits (e.g., 70TB storage, 10k writes/sec) due to growth. Vertical scaling (bigger machines) works temporarily but eventually fails.
- **Definition of Sharding** [02:32] — Sharding is splitting data across multiple machines (shards), each a standalone database with its own storage and connection pool, collectively holding the full dataset. This allows scaling by adding more shards.
- **Shard Key and Distribution** [03:36] — Two key decisions: what to shard by (shard key, e.g., user ID) and how to distribute values across shards (strategy, e.g., range, hash, directory).
- **Properties of a Good Shard Key** [04:51] — A good shard key has high cardinality (many unique values), enables even distribution, and aligns with query patterns (e.g., sharding by user ID for user-centric queries).
- **Examples of Good Shard Keys** [06:24] — For a social media app, sharding by user ID is good due to high cardinality and query alignment. For e-commerce, sharding by order ID is good for order-centric queries.
- **Examples of Bad Shard Keys** [07:41] — Sharding by a boolean (e.g., premium) has low cardinality and limits scaling. Sharding by creation date can cause hotspots if most queries target recent data.
- **Range-Based Sharding** [08:49] — Splits data into ranges (e.g., user IDs 0-10M, 10M-20M). Simple but can lead to uneven distribution, especially with monotonically increasing keys, causing hotspots on newer shards.
- **Hash-Based Sharding** [10:26] — Uses a hash of the key modulo the number of shards to distribute data evenly. However, adding a shard requires reshuffling most data (mod changes).
- **Consistent Hashing** [11:50] — Industry standard: places keys and shards on a virtual ring, minimizing data movement when adding/removing shards. In interviews, default to hash-based sharding with consistent hashing.
- **Directory-Based Sharding** [13:20] — Uses a lookup table to map each record to a shard. Offers flexibility but adds latency and a single point of failure. Rarely the right answer in interviews.
- **Hotspots and Load Imbalance** [16:16] — Even with a good shard key, some shards can get overloaded (e.g., celebrity problem). Solutions: compound shard keys (add suffix to key) or dedicated celebrity shards.
- **Cross-Shard Operations** [18:57] — Queries needing data from multiple shards are expensive. Solutions: cache results, denormalize data, or choose a better shard key. Cross-shard queries should be the exception.
- **Consistency Challenges** [22:32] — Cross-shard transactions are hard. Two-phase commit (2PC) is slow and fragile. Saga pattern uses compensating actions to maintain consistency.
- **Sharding in Interviews** [26:40] — Justify sharding with numbers (storage, write/read throughput). Propose a shard key based on access patterns, choose hash-based sharding with consistent hashing, and discuss trade-offs and growth plans.

### Conclusion

Sharding is a critical system design concept that requires careful consideration of shard keys and distribution strategies. In interviews, justify the need for sharding with concrete numbers, default to hash-based sharding with consistent hashing, and be prepared to discuss trade-offs like hotspots and cross-shard operations.

## Transcript

focusing on one of the core concepts of system design and that is sharding. So interview what is sharding, how do you know what to shard by, how do you distribute the data, what are the main challenges that come up as a result of
typically like to probe into these challenges. And then we'll end really concretely with how you should address or what you should say uh when you bring for those of you unfamiliar, I'm Evan. I'm a former meta staff engineer and the
interview.com. Without further ado, let's get into it. Let's start with a sharding exists in the first place. Basically, the motivation for why we need to shard. And so you can imagine that we just launched our app and our
app has a single let's say AWS RDS Postgress instance, right? So a single database and it's a big one. It has roughly 70 terabytes of storage. It can handle about 10,000 writes per second. And in the early days of our app,
everything is super smooth. Traffic grows, read volume grows, write volume be handled by what is a pretty significantly sized database here. But eventually, maybe inevitably, we outgrow that database. And so maybe it's now
that we've grown to a point where we need 20,000 writes per second, writes per second limit. Or maybe it's that our storage is approaching that 70 terabytes limit. Right? In either case, the database is straining and the
queries are slowing down. Backups are taking forever. It's clear that we've hit some sort of a ceiling. And so what do we do now? Well, the obvious first instinct is what's called vertical scaling. And it's to say, let's just
upgrade to a bigger machine, a bigger database, bigger hardware. And to be fair, this works. This works for a while. And so AWS does offer even larger machines. you can scale up to 140 terabytes of storage, something like
50,000 writes per second depending on what your queries are. And it's worth acknowledging this is a ton of throughput. Um, most companies will never ever hit this. But for the sake of argument, let's say that our app
continues to grow. And so we're global now. Traffic hasn't stopped. Even bigger saturated CPU, storage, IO, everything. Our database is angry. It can no longer handle the load. And so at this point, the issue can't be solved by a bigger
database. Uh instead, it's that no matter how big the database, we simply can't keep up. And so that's when we reach for what is called sharding. And so sharding, there you go. Sharding is the process of
splitting your data across multiple machines so that no single database holds everything. And so each shard is its own standalone database. memory, its own storage, its own
connection pool, and it stores just a subset of the data such that together the shards form the full data set. And so we can now scale storage and read and write throughput by simply adding more shards. And if you start to grow, you
add a fourth shard, a fifth shard, a sixth shard, etc. Now, importantly, sharding solved our scaling issue. That's great. Um, but it introduced new problems like how do we choose how to shard? How do we know which shard to
route our queries to? What happens if we have a particularly hot shard? What happens if one goes down and we need to rebalance? Um, you have to deal with all this new operational complexity that comes from having multiple database
instances. And so these are the trade-offs and the strategies that we're going to explore throughout the rest of this video. How do you shard? And then limitations that come from sharding? The first thing that we need to decide is
how do we shard our data and that naturally breaks down into two questions. The first is what do we shard by? This is going to be the field that we use to group your data which we call the shard key. And so for example, if
you shard by user ID that would be a column in your data and then all data for a given user will live on the same shard. Okay. The second one here is how do we distribute those values across the shards? And so this is the strategy for
mapping a shard keys values to a given machine to a given database. And so for example, we might split user IDs into ranges like we saw in the example above, 10 million to 20 million, 30 million to 40 million, etc. Or maybe we'll hash
little bit later on when we talk about strategies. And so in simple terms, in simple terms, the shard key is how we group our data and the distribution strategy is how we place those groups onto shards. Okay? And so we're going to
start with the first question here, which is choosing a shard key. Let's what our shard key could be in the first place? And uh anytime you're going to design interview, if you're going to talk about sharding, then the first
thing you should do is mention what your shard key is. And you want to be explicit about this. What column are you sharding on and why? And so a good shard key has three properties. And we'll show examples of these in just a moment. So
bear with me. But the first is what we call high cardality. This is basically that we want a field with lots of unique values so that we can spread that data across the shards instead of piling everything onto a few shards. Right? So
basically the the the the high cardality means that we can have a good random or even distribution. And so that leads us to the second point which is directly even distribution and this is that those values should naturally spread out so
that each shard has roughly the same amount of data. Okay. And then the last one here is query alignment. Our shard key should match how we query our data. Concrete example, if most of our queries are let's get all posts for a given
user, then sharding by user ID keeps all of that user data on one shard. And it means that when we want to get all of a user's posts, uh we only need to query one database. We don't need to go query all of the different shards, right? And
so then on the flip side, a bad shard key of course has low cardality. It creates uneven distribution and it forces queries to hit many shards just to answer something simple in many cases. And so this is how you end up
about in a moment like hotspots and and slow cross shard queries, but we're going to aim for good shard keys. Um let's let's look at examples. I got some examples down here for what could make a good shard key. And so let's first
imagine in this top left one that we have a popular social media app and the most common operation is users visiting another user's profile and loading all we've been talking about. now throughout the video. And so, as we've mentioned,
in this case, sharting by user ID is a great choice because it has high cardality. Every user has a unique ID. So, we have tons of distinct values to spread across the shards. It can be evenly distributed. Users tend to arrive
in fairly uniform patterns over time. So, no single shard is going to end up with most of the users. And then lastly, that query alignment. our main queries to get all posts for a given user which maps perfectly because it means we just
need to query one of these shards in order to get a user's posts right for would be that we have an e-commerce site. If we have an e-commerce site where the most popular thing that users are doing is retrieving information
about a single order both creating orders, reviewing orders, checking update statuses on orders, etc. Then charting by order ID makes a lot of reasoning, high cardality, it's fairly evenly distributed, and importantly, it
aligns with our query pattern. But let's look at let's look at some examples of bad shard keys. Maybe this will be even more illustrative. And I said, imagine that you sharted on the value is premium, right? So in your user table,
not premium members. And that's a boolean flag in your database. If you were to shard on this, then this gives you only two groups, premium users and nonpremium users. And that's extremely low cardality. you immediately cap
they fill up you're kind of stuck, right? There's nothing else to split them on if you've chosen that as your shard key. Another bad example which is maybe less intuitive is in the case where you shard by creation date. Um,
specifically if you shard by creation date for an app in which most users are querying the most recent data. And so let's say it's our social media app again and we've sharted by creation data posts. So all the posts from 2023, 2024,
and 2025. Well, what's going to happen here is that all of the traffic is going to go towards shard 3 here because most users are looking for the recent posts and so we're going to end up with that hot spot on shard 3. Right? So, this was
not evenly distributed appropriately. Now that we've talked a bit about what point here, which is how do we distribute those values across the couple strategies. We're going to talk about three of them. And let's start
with what is the most simple though suboptimal option which is called rangebased sharding. And so this is the example that we've been looking at thus far because it's the most intuitive. And with rangebased sharding we take the
example and we just split it into simple ranges. So shard one has all user IDs from 0 to 10 million. Shard two has all user ids from 10 million plus 1 to 20 million and so on. Right? You get the picture. It's super intuitive. Now the
problem is that this can very easily lead to uneven distribution or at least one problem. So let's say that you have your three shards. Your app is in its early days. There's only a million users right now. Then only the first shard has
real data and thus has real load. The other two are sitting there empty. Additionally, maybe more practically is that if you were sharding by user ID, all of your new users are ending up over here, right? If you assume that user ids
are monotonically increasing, then all of your new users are ending up in these higher ranges and all of the queries, writes and reads are coming to shard three because most of the active users on your site are new users, right?
Almost by definition. And so range sharding can work. It's a simple especially if your data naturally falls into these clean ranges and grows intentional about splitting ranges before things get too big and you end up
that one shard taking all the heat as I mentioned. So, this is a fine option. Intuitively, it's a nice place to start, but it's not what most things use in production. And so, let's move on then to what is actually used more often in
to what is actually used more often in production, and that is hashbased. And here to the left before we look over at what's going on in the right. Um, but the industry default is what's called hashbased sharding. Here's how it works.
It's pretty simple. Instead of us just assigning ranges, what we do is we take assigning ranges, what we do is we take a hash of the key, so whatever our shard key was, like the user ID, and then we mod it by the number of shards that we
have, and that will tell us which shard that we should put uh this particular row or set of data on. Uh, the hash function basically scramles up the input, right? randomizes it so that we spread really evenly, perfectly evenly
even across, in our case these three shards, right, the n shards. So that's a really nice big win. We get solid even distribution, which we talked about being important earlier. Um, but there's still some some major issues with this.
And the first is around rebalancing. And so if you never ever need to add or has to move, right? Imagine that we added a new shard here. Well, now this mod has turned into mod 4 and almost nothing mod 4 versus mod 3 is going to
land up on the same shard. So, tons of data is going to have to move. redistributed. It it's a it's a huge reshuffleling of our data, which is a total nightmare operationally, right?
And so, this is where consistent hashing comes in. And you've probably heard the have a full video on it. I'm going to out. It's pretty short. It goes over consistent hashing, but the short
version is that instead of using that simple modulo, consistent hashing places both the keys and the shards on this virtual ring. And the way that it works is that you hash, you put you go onto the ring to wherever that hashed key
lands and then you just walk right until you find that database. And so there's called virtual nodes. all of this which is in that video which effectively
eliminates that giant reshuffleling problem. Right? So the only thing to know in the context of sharding is that the industry standard is hash hashbased consistent hashing in order to make scaling smooth. Now, in the context of
an interview specifically, um if you say, "Hey, we're going to shard and we're going to shard by user ID." Your interviewer's default expectation is that you're using hashbased sharding uh with consistent hashing. In many cases,
Especially if you're senior plus, that's the expectation. There's no reason to even bring it up. If you are more junior, mid-level, they might ask you, "How is this sharding happening?" in which case you can inform them about how
hashbased sharding and consistent hashing actually works. Um let's look at the last one here now and this is something called directorybased sharding. And so instead of using a formula to decide where data
lives, directory sharding uses a lookup table. And so for each record, say each user, you store which shard they belong to in this lookup table. And so you simply on each read or write have to first come here, find out which shard
they belong to, and then go to the right shard specifically. And so the big advantage here is flexibility. If one user suddenly becomes super popular and can move them onto their own shard easily by just updating this mapping. If
shards start to get overloaded, you can redistribute with this mapping. um you can basically implement all of this custom sharding logic by being explicit about which users or which shard key matches to each shard respectively. But
guys might be thinking this as you're hearing me talk through this and that's that every single request now has extra latency. It needs to first look up here query the shard as opposed to just one query to the shard. And so that's two
requests now for every single lookup, which is going to add a bunch of extra latency. And it also, maybe even more importantly, is going to create a single point of failure where if this directory goes down, well then we're pretty
because we have no idea where all of our data exists on each of these shards, right? So directory based sharding has its place. It's great when you absolutely need that maximum flexibility and you can inform you can uh excuse me,
and you can inform you can uh excuse me, you can afford this extra hop, but very important in a system design interview, it's almost never the right answer. And failure. It adds the extra latency from
invite a bunch of follow-up questions that might derail your whole interview. Right? So my suggestion to you is in practice, especially in interviews, just default to your hashbased sharding with consistent hashing. Know that the others
exist in case you need them, particularly in order to get out of um, we'll talk about in a moment. But this one's your default. It's your bread and butter and it's the one that you should know best.
popular feature on hello.com, guided practice. It's an interactive tool that interviews step by step using that hello interview delivery framework. You're the non-functional requirements to the core entities API routes all the way
dives drawing on the whiteboard and getting real-time feedback on what you're doing well and where you can improve by a model that Stephan and I have spent hundreds of hours tuning.
We've expanded the library to 25 of the most common system design interview questions now and we're constantly adding more. So candidates absolutely love this feature. I think you will too. Check it out at hello.com. Link will be
in the description. All right. Now that we know all about how to shard, let's along with sharding because frankly these are the follow-up interview going to throw at you and that you obviously want to be ready for. And so
the first and the most common problem is around hotspots or load imbalance. So, let's look at that one first. Um, even with a good shard key, some shards can end up taking on way more traffic than others. Let's let's give the classic
example of what's called the celebrity problem. And so, let's say we sharded by user ID, and Messi happens to land on shard one, of course, Leon Messi, the the famous soccer player. And so, anytime someone views his profile or
comments on his posts or likes something of his or sends him a message, all of of his or sends him a message, all of that traffic is going to shard one. Now suddenly shard one is orders of magnitude larger in its right throughput
than the other shards, right? Because messy is there. And so most other ones sit there cold where this one got really really hot. And so what do we do? Well, the first solution is what's called a a compound shard key. You guys have seen
me use this in other videos. And it's instead of sharding purely based on user instead of sharding purely based on user ID, you add some additional suffix or some piece of data before hashing. So whereas before
whereas before it might have looked like this, right? In order to get that key, now it can be user ID plus n where maybe n is a number distribute this over. Or if you want to further distribute by time, you could do
something like this, right? You can add another column here. But the point being is that by adding something else uh to the input of the hash function, we're going to further distribute in this case Messi's posts across multiple shards,
we can do is that you can have, and this one's fairly popular as well, a dedicated celebrity shard. And so this is where you can detect the hightraic users and move them into their own specific shard. And so maybe you end up
with a shard for here. This is the celebrity shard. Maybe it's even bigger, like it has special hardware. And now we use that directory based lookup to say, hey, if you're a celebrity, now the thing's a little big, but you guys
get my point, right? Let's first look here. If you're a celebrity, well, then I'm going to route you to the celebrity shard. Otherwise, we're going to do the and you're going to go to your your normal shard, right? And so, most
systems won't end up needing this. Um, but if your platform has extreme outliers like a social media app does in this case with Messi, then it's a really powerful tool, right? You either want to append here with compound shard keys or
have a dedicated shard for celebrities. Now, the next most common issue that you run into is something called cross shard operations. And so this happens when your data lives on multiple machines. So that any query that needs information
becomes expensive because instead of hitting a single shard, you need to wait or you need to fan out and query in some cases many or even all of the shards and that back to the user, right? And so this usually happens when your query
we talked about earlier. And so if we were to shard users by user ID in the example we keep giving, uh then a request like get user 123's profile is shard. it's going to be fast and it's going to be quick. But if the query was
like, give me the top 10 most popular posts across the whole platform. Well, now we have to go get the most popular parts from uh posts from each shard, bring them into memory, right? Aggregate all 30 of those, rank them, and then
return the top 10. And you can see how obviously that's much more expensive. eliminate cross shard queries completely. It's it's unfeasible. But the first line of defense is of course choosing a good shard key that aligns
you don't have them happen that often. But even with a perfect shard key, uh when you have something like top posts in the example that we've shown here. So so what can you do? Well, the first and maybe most common solution is that you
can cache the results of these expensive crossshard queries. So if I had some cash here, maybe something like Reddus, then yes, the first time a user asks for be expensive. We're going to do that scatter gather. We're going to query all
aggregate, but then we're just going to cache it. And so the next time they ask, cache, right? So you get one expensive one and then everything else hits the cache. Maybe we put an expiration on this for just like 5 minutes. And this
of course has us playing with that compromise where we are trading latency for consistency or the staleness of our data because now what's going to happen later are actually going to going to get the top 10 posts from 4 minutes ago not
from right now but in most cases feeds leaderboards trending pages etc. That's a worthwhile trade-off. Uh and so it's one that we make. Another option is that you can denormalize your data so that related information lives together. And
so denormalization of course is the process of repeating data uh such that you're making your queries quicker at the expense of multiple writes. And so you need to go to shard one and shard
a lot. And so what you could do is you could take the data from shard 2 and also put it alongside that table in shard one where you're uh you know constantly making this query. Now you only need to hit shard one and you get
the data but that data lives on both shard one and shard two. So now on writes you have to write it in two places. And so this is another trade-off of course right now you are trading making rights more complex but making
reads stay within a single shard. And so, you know, classic scaling trade-off. Pay a little extra on on rights, but make reads faster and cheaper. It all it requirements whether or not this is right. But the main takeaway for you in
constantly querying across all shards for a common use case. That's a signal for a common use case. That's a signal that either e most importantly or e that either a most importantly you chose the wrong shard key. So, wrong shard key.
wrong shard key. So, wrong shard key. two that you should cache or premputee like we showed in that example or three you should denormalize your data in cross shard queries should be the exception. They shouldn't be the norm.
And then last up in terms of the main problems that come up is consistency. And so when all data lives on a single database then transactions database transactions they're super easy. Let's let's kind of root this in an example.
The classic banking example, you have Bob who has a banking account with $10 and Alice who has a banking account with $10. And Bob wants to send $5 to Alice, right? Well, in a traditional relational database, this is one atomic
This is what the database transaction would look like. We remove $5 from Bob. We add $5 to Alice. And the atomic nature of this transaction makes sure that both of these commands succeed or neither of them succeed. Right? So we
never end up in an inconsistent state. But once Bob and Alice live on different versus shard three, then things start to get messy because and not the same messy
as as earlier, right? They start to get messy uh in the bad way. Uh and that's because now these updates can't happen in one atomic operation. And so what happens if we do this deduction of Bob, but then this increase to Alice fails or
up in that inconsistent state which is bad. And so the textbook solution which is something called two-phased commit oftentimes denoted as 2PC like that. Uh
and basically there's a central coordinator and that central coordinator first asks all shards, hey are you guys ready to do this transaction and then it waits for everyone to say yes before telling them all okay now it's time that
you can commit. Um, and this ensures the consistency and it sounds great in theory. In practice, two-phase commit is actually pretty slow and fragile. Uh, down in the middle of it, then the whole thing can get stuck and you end up in
to get out of. And that's why most production systems actually try to avoid 2PC to some extent. And so what can you do instead? Well, option one for fear of of being annoying here would be well try to avoid cross charge transactions,
to the extent that you can if you have a transaction try to make sure that all that data is on the single database um that should be your your golden rule to achievable as is evidence with our example here. Alice and Bob exist on
we could guarantee that the two people who are involved in in in our bank transaction exist on the same shard, right? And so another option is Another thing you might have heard the buzz term for. And so this works
basically using a sequence of smaller operations. Each action has what's called a compensating action that can be run in to get into too much detail here. I'm going to leave going deep in saga
patterns. We actually have a scaling rights write up which I'll put in the description that you can read more of. But the basics is this. Step one, deduct five from Bob on shard two or on shard three, excuse me. Step two, add five
bucks to Alice on shard one. And then if step two fails, we don't magically roll everything back. Instead, we run what is that compensating action for step two, which I had mentioned, which is that we're going to refund Bob his $5. And
don't end up in a broken state because opposite compensating reaction such that if anything fails, we'll run that compensating um action in order to get back to the state that we want it to be
in. So, uh, a little hard to describe in brief, but look up Saga pattern on your because I don't want to go into too much detail here. But the mental model that you should be thinking of here when it comes to maintaining consistency is um,
basically first try to avoid cross shard transactions in the first place. If you do have them, the saga pattern is really useful. It's such that instead of one big transaction, you chain smaller steps together, each of which have a
corresponding undo action associated with them. All right, lastly before we thing is let's talk about how sharding comes up in system design interviews. in your interview during your deep dives
interview when you're satisfying a non-functional requirement about scaling, you're going to head over to your database and you're going to think, hm, from the perspective of both storage, write throughput, and in some
storage, write throughput, and in some cases, read throughput, do I reach any of the capacity limits, and can I justify that I do? If yes, I need to me show you what that looks like, right? Specifically, starting with storage, I
could say something like, well, we have 500 million users with 5 kilobytes of data each, and so that's 2.5 tab of data. A single Postgress instance is going to handle that. So we don't need to shard. But if we ended up growing 10
or 100x, then we would shard. Okay. Write throughput. We're expecting about single database would struggle with this right load. So we should probably shard. Read throughput. Similarly, even with
million daily active users making multiple queries each, we'll need to Probably do some math about how many read queries that would end up being and thresholds. Now, I put this in red because this is important, and you saw
this with the first example. You don't always need to shard. In many of the it's the reflexive nature of most candidates. They say, "Oh, I need to shard, and I'm going to shred by this." Um, but that's wrong. Like, modern
in our our intro example, you had a Postgress database with 140 terabytes of Postgress database with 140 terabytes of storage. That's a ton, right? Uh 50,000 writes per second. And so it's sometimes the case in these interviews where it's
show your interview actually based on this math I don't need to shard right 500 million users 5 kilobytes of data that's only 2.5 terabytes of data and we're going to have limited throughput so no need to sharp but in the case
where you do prove that sharding is necessary then what do you say? Well you The first thing that you're going to do is you're going to propose a shard key based on your access pattern. And so, for example, for this social media app,
most queries are user centric. When someone loads their feeds, we're followers, and their likes. And that's all scoped to a single user. So, I'm going to shred by user ID. Easy. The second one, you're going to choose your
this is where you could say, I'd use hashbased sharding with consistent hashing to hash the user ID, distribute users evenly across the shards. Now, as to skip two. This is kind of the default. This is what your interviewer
you're going to shred by user ID. But for the more junior roles, junior and third thing that you're going to do is you're going to call off call out those trade-offs. And so you might say the trade-off is that global queries are
going to become more expensive. If we need trending posts across all users, then we'll have to query all the shards and aggregate the results. Um, but you know, we could handle this by caching trending content, precomputing it with a
where you'll talk about those trade-offs we discussed. And then the fourth is you growth. And so you know we're going to start with 10 shards which gives us room hashing is going to make it easier for us to add shards later and reshard the
data if we need to and and we end up needing more capacity. Right? So that's conversation should be simple. It should flow naturally and most importantly it should be justified based on the numbers that you calculate either on storage
right or read throughput. Awesome. Um, okay. I hope that this was useful to you all. I know this was just a quick hit on sharding. We have the read. It has a little bit more detail, but this is a foundational core concept
for your interviews. Go ahead and leave some questions, comments, anything I got wrong, I'll be in the comments responding to them. Uh, check out the website helloview.com. Lots more content just like this. Check out the YouTube
channel. Plenty more videos and more on the way. So, thank you all for watching. Best of luck with the upcoming interviews and I'll see you all soon.