Handling Large Blobs hard
Historically, why did S3 advise against sequential key names (e.g., `2023-01-01-log`, `2023-01-02-log`) for high throughput?
- A Hot Partitions. S3 routes requests based on key prefixes. Sequential keys all landed on the same partition server, overloading it. Random prefixes (hashes) spread load across partitions.
- B It confused the search.
- C It wasted space.
- D It was less secure.
Answer: A. Hot Partitions. S3 routes requests based on key prefixes. Sequential keys all landed on the same partition server, overloading it. Random prefixes (hashes) spread load across partitions.
Modern S3 automates splitting, but adding entropy to prefixes is still safer for massive spikes.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Why do modern sites serve images in WebP or AVIF format?
- What does the acronym BLOB stand for?
- Why do we sometimes convert binary images to Base64 strings?
- What is an 'Origin Shield' or 'Mid-Tier Cache' in a CDN architecture?
- For a feed with 100 images, why use 'Lazy Loading'?
- How does HLS/DASH handle a user moving from WiFi to 4G (Variable Bandwidth)?