You want a Redis key holding only the 100 most recent events for each user, without it growing forever. Show how LPUSH together with LTRIM implements that, and explain what the trim actually costs and why the two commands should be issued together.

## The idiom Redis has no built-in maximum length for a List, so bounded structures are built by convention: push the new element at one end and trim the far end away. LPUSH feed:42 event; LTRIM feed:42 0 99 LTRIM key start stop is subtractive: it keeps the specified inclusive index range and removes everything outside it. Indexes are zero-based and negatives count from the end, so LTRIM key 0 99 keeps the hundred newest when pushing with LPUSH, while LTRIM key -100 -1 keeps the hundred newest when pushing with RPUSH. Out-of-range values are clamped, so trimming a list shorter than the cap is a harmless no-op, and a range selecting nothing empties the list, deleting the key. This gives a fixed memory bound per key: cap times average element size. For a timeline of a hundred short events that is a few kilobytes, so millions of user feeds become a predictable budget instead of unbounded growth. ## Why the pair must be atomic Between LPUSH and LTRIM the list is momentarily over the cap, and if the client dies in that gap the list stays over the cap until the next push. One extra element is harmless, but the failure compounds if trims are systematically skipped. Wrapping the pair in MULTI/EXEC makes them execute as one unit, so no other client observes the intermediate state and neither command can happen without the other. A pipeline is not a substitute: it batches round trips, but the server may interleave other clients' commands between them, and a disconnect mid-pipeline can leave only the push applied. A tiny Lua script gives the same atomicity as MULTI/EXEC and is convenient when the cap is computed. ## What the trim costs The documented complexity is O(N) with N the number of elements removed. This is the number most candidates get wrong, and the consequences follow directly. Trimming after every push means each LTRIM removes at most one element, so the amortised cost is constant and it is cheap enough for the write path. Trimming lazily — every hundredth push, or in a nightly job — saves a command per write but concentrates the work: a single LTRIM removing 100,000 elements is a long-running command, and while it runs no other command is served, since Redis executes commands one at a time. The same trap appears when a cap is reduced: shrinking a million-element list to 100 in one LTRIM is a large synchronous deletion. The safe form when a list is already huge is to trim in steps — repeated LTRIMs each removing a bounded number of elements — or, if the list is disposable, UNLINK the key, which reclaims memory in a background thread instead of inline. ## Related pitfalls A capped list bounds count, not bytes. If elements vary wildly in size, a hundred entries can still be megabytes; cap by count and enforce a size limit on payloads, or store large bodies elsewhere and keep only ids in the list. Remember also that a List permits duplicates and does not deduplicate, so a capped list is a log of recent events, not a set of distinct ones. And if a trim ever empties the list the key is deleted, taking any TTL with it — so a per-key expiry must be re-applied by the writer rather than assumed to persist.