Data Management

Resharding means moving live data between servers while the system keeps running, so the main risks are reads getting stale or wrong-shard answers mid-move and overloading production during the copy. Teams usually write to both old and new locations, copy the history over in the background, verify it matches, then switch reads over.

Either the client's clock is off so the link looks expired too early, or the upload got retried in a way that changed something about the request (like its size), so it no longer matches what was originally signed. Both look like the same error but need different fixes.

Using claim check for every message, even tiny ones, adds an extra network call and a second system for no benefit -- small payloads fit on the bus fine. It's worth it only when payloads are large.

If the data changes about as often as it's read, if slightly old data would cause real harm, or if a simple index or better query would already be fast enough, adding a materialized view just adds extra moving parts without enough benefit. Better indexing, caching, or just optimizing the query is often the simpler fix.

Pick a shard key that keeps each tenant's data together, since almost every query is scoped to one tenant — but plan for the fact that some tenants will be far bigger than others, or your biggest customer alone can overload a single shard. Getting it wrong means either slow cross-shard queries for a single tenant, or one giant customer crushing whichever shard they land on.

Stop relying on one shared master key for everything. Instead, make each link individually trackable, for example by making tokens expire very fast, or by adding a lookup list of blocked token IDs that gets checked before the request reaches storage, so you can kill one without touching the rest.

The cache only remembers things it successfully found. If a key never exists, the database always says 'not found' and nothing ever gets saved to the cache, so every repeat request goes straight to the database again. The fix is to also cache the 'not found' answer for a little while.

Rebuilding from hundreds of millions of events isn't instant or free — it takes real time, compute, and can strain the live system if done carelessly. You need a plan for how long it takes, whether old users see stale or half-built data during the rebuild, and how to handle old event formats safely.

DynamoDB has a built-in feature called a Global Secondary Index that does most of this automatically — the database keeps it in sync for you. You'd only build your own index table by hand if you need something the built-in version can't do, like guaranteed instant consistency or very complex derived keys.