Feed / timeline
API servers → Redis → Cassandra. A celebrity post makes one key take 60% of the traffic.
What this architecture teaches
Partitioned databases scale by spreading keys across partitions — as long as traffic is spread too.
Here one key (a viral post) receives 60% of the reads. Its partition exceeds its limit and throttles, while the other nineteen partitions are mostly idle. Total capacity is irrelevant; the hot key only lives in one place.
Fixes are about the key, not the cluster: cache the hot item, shard it into several keys, or choose a partition key with more distinct values.
What to look for
- Total Cassandra capacity is far above the load
- One partition still exceeds its limit
- Hot keys need sharding or caching, not more nodes
Components
Android users — Android app (Traffic source)- feed-api — Server group (Server group)
feed-cache — Redis (Cache)
timeline-db — Apache Cassandra (Wide-column DB)