--- title: 5/30 Days System Design Questions! | daily.dev description: A system design challenge presenting four database sharding strategies for a Postgres orders table at 500M rows with a specific e-commerce workload: 80%... canonical: https://daily.dev/posts/5-30-days-system-design-questions--siku4jqk8 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 5/30 Days System Design Questions! | daily.dev og:description: A system design challenge presenting four database sharding strategies for a Postgres orders table at 500M rows with a specific e-commerce workload: 80%... og:url: https://daily.dev/posts/5-30-days-system-design-questions--siku4jqk8 og:image: https://api.daily.dev/og/posts/siKU4jqk8.png og:image:alt: 5/30 Days System Design Questions! og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 5/30 Days System Design Questions! **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 396 upvotes · 22 comments ## Summary A system design challenge presenting four database sharding strategies for a Postgres orders table at 500M rows with a specific e-commerce workload: 80% customer-centric reads, 15% analytics, 5% writes at 400 RPS. The four options are hash sharding on order_id, range sharding on created_at, directory-based sharding, and consistent hashing with virtual nodes. The post teases that one option is the correct fit and one is a common senior engineer trap, with the full answer promised in comments. ## Content 4 database sharding strategies. 4 completely different scaling outcomes. One wrong choice and you're melting a primary on Black Friday. Your Postgres orders table just crossed 500M rows. Range scans that used to take 40ms are creeping past 800ms. Vertical scaling is dead. You need to shard. Here is the workload: • orders = 500M rows, growing 3M/week • 80% reads = "customer X's last 30 days of orders" • 15% reads = analytics joins on date ranges • 5% writes = new orders (steady 400 RPS, 2x on sale days) Which strategy do you pick? A) Hash sharding on order_id — even distribution, no hotspots. B) Range sharding on created_at — keeps time-series queries local. C) Directory-based sharding — lookup table maps customer to shard. D) Consistent hashing with virtual nodes — easy rebalancing on scale-up. All four are real strategies you'll find in production. But only one is the right fit for an e-commerce workload where 80% of reads are customer-centric. One of the wrong answers is the senior engineer trap. It sounds sophisticated, shows up in every YouTube tutorial, and will quietly wreck your query latency on this exact workload. I'll drop the full breakdown and the correct answer in the comments. If your team is debating a database migration, repost this — someone on your team is about to pick the wrong strategy. What's your answer: A, B, C, or D? 👇 #SystemDesign #Databases #PostgreSQL #BackendEngineering ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 43 upvotes > Answer: C — Directory-based sharding ✅ > > > Here is why the other three trick smart engineers: > > > Why C wins (Directory-based): > > 80% of reads are "customer X's orders." You want every order for a customer on exactly one shard. A customer-scoped read hits one node, no scatter-gather fan-out. > > You keep a customer_shard_map table (cached in Redis). If shard 3 gets hot, you migrate specific heavy customers (whales) without rehashing anything. Targeted rebalancing is the superpower. Figma, Notion, and Slack do this. **@joudawad** · 15 upvotes > Why A is the trap (Hash on order_id): > > The classic tutorial answer: "Hash the primary key!" It wrecks you here. A single customer's 200 orders scatter across all shards. Every read becomes a 4-shard fan-out gated by your slowest node. P99 latency goes up. **@joudawad** · 13 upvotes > Why B is wrong (Range on created_at): > > Creates a hot shard by design. Every new order writes to the same shard. Your newest shard absorbs 100% of writes and 70% of reads. On Black Friday, this shard melts while others sit idle. **@joudawad** · 4 upvotes > Why D is wrong (Consistent hashing): > > Great for uniform data, but you can't migrate specific heavy tenants. If four whales land on the same shard, you are stuck. **@nathanielwhittingham** · 2 upvotes > Could you use Kafka for micro services to simplify and speed up the architecture --- Tags: [#career](https://daily.dev/tags/career), [#backend](https://daily.dev/tags/backend), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/5-30-days-system-design-questions--siku4jqk8) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/5-30-days-system-design-questions--siku4jqk8","headline":"5/30 Days System Design Questions!","text":"A system design challenge presenting four database sharding strategies for a Postgres orders table at 500M rows with a specific e-commerce workload: 80% customer-centric reads, 15% analytics, 5% writes at 400 RPS. The four options are hash sharding on order_id, range sharding on created_at, directory-based sharding, and consistent hashing with virtual nodes. The post teases that one option is the correct fit and one is a common senior engineer trap, with the full answer promised in comments.","url":"https://daily.dev/posts/5-30-days-system-design-questions--siku4jqk8","datePublished":"2026-05-10T17:20:19.206Z","dateModified":"2026-05-10T17:21:14.058Z","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0","description":"Principal Solution Architecture ","worksFor":{"@type":"Organization","name":"Metalab","logo":"https://www.google.com/s2/favicons?domain=metalab.com&sz=128"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":81840}},"image":"https://media.daily.dev/image/upload/s--uAJgBpqT--/f_auto/v1778433647/posts/siKU4jqk8?_a=BAMAMiWQ0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":396},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":22}],"comment":[{"@type":"Comment","text":"Answer: C — Directory-based sharding ✅\nHere is why the other three trick smart engineers:\nWhy C wins (Directory-based):\n80% of reads are “customer X’s orders.” You want every order for a customer on exactly one shard. A customer-scoped read hits one node, no scatter-gather fan-out.\nYou keep a customer_shard_map table (cached in Redis). If shard 3 gets hot, you migrate specific heavy customers (whales) without rehashing anything. Targeted rebalancing is the superpower. Figma, Notion, and Slack do this.","datePublished":"2026-05-10T17:21:22.574Z","url":"https://daily.dev/posts/siKU4jqk8#c-Va89R4exc","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":43}},{"@type":"Comment","text":"Why A is the trap (Hash on order_id):\nThe classic tutorial answer: “Hash the primary key!” It wrecks you here. A single customer’s 200 orders scatter across all shards. Every read becomes a 4-shard fan-out gated by your slowest node. P99 latency goes up.","datePublished":"2026-05-10T17:21:27.754Z","url":"https://daily.dev/posts/siKU4jqk8#c-VUV1Z2r50","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":15}},{"@type":"Comment","text":"Why B is wrong (Range on created_at):\nCreates a hot shard by design. Every new order writes to the same shard. Your newest shard absorbs 100% of writes and 70% of reads. On Black Friday, this shard melts while others sit idle.","datePublished":"2026-05-10T17:21:32.224Z","url":"https://daily.dev/posts/siKU4jqk8#c-zOAaoiaxI","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":13}},{"@type":"Comment","text":"Why D is wrong (Consistent hashing):\nGreat for uniform data, but you can’t migrate specific heavy tenants. If four whales land on the same shard, you are stuck.","datePublished":"2026-05-10T17:21:36.819Z","url":"https://daily.dev/posts/siKU4jqk8#c-HIVTmq2cr","author":{"@type":"Person","name":"Joud Awad","url":"https://daily.dev/joudawad","image":"https://media.daily.dev/image/upload/s--dOB9RaXY--/f_auto/v1773320801/avatars/avatar_iaC4JsBU0lV8wBsc85fSh?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"Could you use Kafka for micro services to simplify and speed up the architecture","datePublished":"2026-05-13T09:04:33.645Z","url":"https://daily.dev/posts/siKU4jqk8#c-pUUC0MVpZ","author":{"@type":"Person","name":"Nathaniel Whittingham","url":"https://daily.dev/nathanielwhittingham","image":"https://lh3.googleusercontent.com/a/ACg8ocKZYsBdrGMTTjxW9FNVTp8CeLmccmY4_OT82zLIDmdnKN1Gp2K0=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh","name":"Joud Awad"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Joud Awad","item":"https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh"},{"@type":"ListItem","position":3,"name":"5/30 Days System Design Questions!"}]} ```