Most systems in software engineering are built to preserve data forever, or at least until someone explicitly decides to delete it. “Stories” — the now-familiar format of photos and short videos that appear at the top of a social app and vanish exactly 24 hours after posting — flip that assumption on its head. This is a system deliberately engineered to forget, on a precise schedule, at massive scale, and getting that forgetting right turns out to be a genuinely interesting distributed systems problem.

The format traces back to a single product launch in 2013, when a messaging app introduced a feature that let people share a photo or short video that any of their friends could view, but which disappeared permanently after 24 hours. The idea was a deliberate departure from the permanent-record model that had defined social media up to that point — a lower-pressure way to share a passing moment without it becoming part of a permanent, searchable history. It proved popular enough that within a few years, most major social platforms had shipped their own version of the same format, adopting the same core mechanic: post something, it’s visible for a day, then it’s gone.

From an engineering standpoint, this format asks for a genuinely different set of guarantees than a typical content-sharing feature. Every other system in this tutorial series has assumed content should persist indefinitely and treated deletion as a rare, exceptional operation. Here, deletion isn’t exceptional — it’s the default, scheduled, guaranteed outcome for every single piece of content the system stores, and it needs to happen reliably, precisely, and at a scale of millions of pieces of content expiring continuously, all day, every day.

2.1 Sub-problem 1 — guaranteeing precise, reliable expiration at scale

The most distinctive challenge here is making sure content actually disappears when it’s supposed to — not “eventually, whenever a cleanup job gets around to it,” but within a tight, predictable window of the actual 24-hour mark. At the scale of millions of pieces of content being created continuously throughout the day, a naive approach — a periodic batch job that scans everything and deletes what’s expired — either runs too infrequently (leaving expired content visible for an unacceptably long window) or too frequently (creating a constant, expensive scanning burden that doesn’t actually scale well as content volume grows).

2.2 Sub-problem 2 — an entirely different caching philosophy than a typical media system

The previous tutorial in this series built an entire architecture around the idea that image content is immutable and can be cached aggressively, indefinitely, since it never needs to become unavailable. Here, that assumption is inverted: every piece of cached content has a hard expiration, and caching layers — including any CDN involved — need to respect that expiration precisely, rather than treating long cache lifetimes as an unambiguous good, the way the previous tutorial did.

2.3 Sub-problem 3 — the “story ring” is its own lightweight fan-out problem

Before a viewer can watch anyone’s story, they need to see which of the people they follow currently have an active story at all — typically shown as a row of avatars at the top of the app. This is a distinct, smaller-scale version of the fan-out problem covered in an earlier tutorial in this series: whenever someone posts a new story, everyone who follows them needs to eventually see an indicator that a new story is available, and that indicator itself needs to stop showing once the story expires.

2.4 Sub-problem 4 — viewer tracking with a hard time boundary

Just like the profile-view tracking problem covered elsewhere in this series, story creators typically want to know who has viewed their story. But here, the entire viewer history for a given story is itself bounded by the same 24-hour window — once a story expires, its view history becomes irrelevant (and, depending on the platform’s privacy stance, may need to be deleted along with the content itself), which is a meaningfully different retention requirement than the indefinitely-retained view history covered in that earlier system.

3.1 Functional requirements

• Users can post a photo or short video as a story, visible to their followers (or a restricted subset, like a “close friends” list).
• A story automatically becomes inaccessible exactly 24 hours after posting, with no manual action required.
• Users see an aggregated “story ring” showing which followed accounts currently have at least one active story.
• Multiple stories from the same user within the window are viewed as an ordered sequence.
• Story creators can see who has viewed their story, for as long as that story remains active.

3.2 Non-functional requirements

• Guaranteed, timely expiration — the headline requirement: expired content must become inaccessible within a tight, well-defined window of its actual expiry time, not “eventually.”
• High read throughput — story viewing, like most social content, is read-dominated, and needs to remain fast even as content volume and viewer count scale.
• Bounded storage growth — unlike a permanent content platform, total storage should stay roughly proportional to one day’s worth of content, not grow unboundedly over time, since content is continuously expiring as new content arrives.
• High availability — consistent with the AP-leaning stance used throughout this tutorial series, brief staleness (a story ring that updates a few seconds late) is preferable to the whole system becoming unavailable.
• Privacy-respecting deletion — expired content, and ideally its associated viewer history, should be genuinely removed, not merely hidden from the UI while still technically retrievable.

3.3 Back-of-the-envelope capacity estimation

Let’s work through realistic numbers for a platform with 500 million daily active users, broadly consistent with the scale of the largest real-world platforms offering this feature.

3.4 The storage growth curve looks fundamentally different here

This is worth sitting with, because it’s a genuinely different shape than every other system covered in this series. The photo-sharing platform’s storage grew by tens of petabytes every year, accumulating indefinitely. Here, because content is constantly expiring at roughly the same rate new content arrives, total active storage stays roughly flat over time, regardless of how long the platform has existed — a direct, structural consequence of the 24-hour expiration requirement, and a meaningfully different cost and capacity-planning picture from a system built around permanent content.

3.5 Read traffic estimation

The read-to-write ratio is once again heavily skewed toward reads — consistent with most of the systems in this tutorial series, though the exact multiplier differs from any of them. This confirms that the same broad instinct applies here as elsewhere: optimize aggressively for fast, cheap reads. But the capacity picture is genuinely distinctive in one specific way worth restating: this is very likely the only system in this tutorial series where the relevant capacity question isn’t “how do we handle unbounded growth” but “how do we handle a roughly constant, self-limiting steady state” — which changes the capacity planning conversation considerably.

The defining feature of this architecture, worth stating explicitly before walking through the components, is that expiration is handled natively at nearly every layer, rather than being bolted on as a separate cleanup process. This is a deliberate design principle this tutorial returns to repeatedly: whenever a storage or caching system offers native, built-in support for automatic expiration, using it directly is almost always preferable to building custom deletion logic on top of a system that wasn’t designed for it.

4.1 Story Service

Handles story creation: validating uploaded media, storing it, recording metadata with an explicit expiration timestamp, and publishing an event so other parts of the system (notably the Story Ring Service) can react to the new content.

4.2 TTL-Native Store

The metadata store for story records, chosen specifically because it offers built-in, automatic expiration of records after a specified duration — covered in real depth in the next section, since this is the single most important infrastructure decision in the whole design.

4.3 Media Blob Storage

Stores the actual photo or video bytes, configured with an object lifecycle policy that automatically deletes objects after a set duration slightly longer than the content’s logical 24-hour window, providing a backstop cleanup mechanism independent of the metadata store’s own expiration.

4.4 Story Ring Service & Active-Story Index

Maintains, for each user, a lightweight, self-expiring index of which followed accounts currently have at least one active story — the mechanism behind the “story ring” UI, covered in its own dedicated section shortly.

4.5 Viewer Tracking Service & Viewer Store

Tracks who has viewed a given story, using the same TTL-bound principle as the primary content store, since viewer history for an expired story is no longer meaningful and, for privacy reasons, generally shouldn’t persist past the content’s own lifetime.

4.6 CDN with bounded TTL

Unlike the indefinite, aggressive caching used for permanent photo content elsewhere in this tutorial series, the CDN layer here must be configured with cache lifetimes that respect the content’s own 24-hour expiration — a story’s cached bytes should become unavailable at or before the same moment the content officially expires, never meaningfully after.

This section addresses the headline challenge directly: how do you make sure millions of pieces of content actually disappear, reliably, close to their exact expiration time, without building an expensive, error-prone custom cleanup system?

5.1 The anti-pattern — a periodic sweep job

The naive approach is a scheduled batch job that periodically scans all stories, checks each one’s age, and deletes anything past 24 hours. This has two real problems. First, precision is tied directly to how often the job runs — a job that runs every hour means expired content can remain visible for up to an hour past its true expiration, which is a meaningfully long, user-visible violation of the product’s core privacy promise. Running the job more frequently to tighten that window means repeatedly scanning a large, continuously growing dataset, which becomes an increasingly expensive, poorly-scaling operation exactly as content volume grows — the worst possible direction for a cost to scale in.

5.2 The right approach — native TTL support in the storage layer itself

Several widely-used distributed storage systems support automatic, per-record expiration as a first-class, built-in feature, and using this directly is dramatically more efficient than any custom sweep-based alternative.

The common thread across all three: expiration is handled by the storage engine’s own internal machinery, which is built specifically to do this efficiently at scale, rather than by application-level code that has to rediscover and reimplement the same problem. This is a genuinely important, broadly-applicable engineering principle worth internalizing well beyond this one system: when a storage system already offers a native mechanism for a problem you’re facing, use it, rather than building custom logic on top of a system that wasn’t designed to support that behavior efficiently.

// Storing a story with native TTL, using a Redis-style client
public class StoryRepository {

    private final RedisClient redis;
    private static final Duration STORY_TTL = Duration.ofHours(24);

    public void saveStory(Story story) {
        String key = "story:" + story.getStoryId();
        String value = serialize(story);
        // TTL is set directly on the write itself - no separate cleanup job.
        redis.set(key, value, STORY_TTL);
    }

    public Optional<Story> getStory(String storyId) {
        String value = redis.get("story:" + storyId);
        // If the key has expired, Redis has already removed it -
        // this simply returns empty, no extra check needed on the read side.
        return value == null ? Optional.empty() : Optional.of(deserialize(value));
    }
}

// The equivalent idea using a Cassandra-style store, where TTL
// is set per-write using CQL's native TTL clause
public class CassandraStoryRepository {

    private static final int STORY_TTL_SECONDS = 24 * 60 * 60;
    private final CqlSession session;

    public void saveStory(Story story) {
        session.execute(
            "INSERT INTO stories (story_id, owner_id, media_object_id, created_at) " +
            "VALUES (?, ?, ?, ?) USING TTL ?",
            story.getStoryId(), story.getOwnerId(), story.getMediaObjectId(),
            story.getCreatedAt(), STORY_TTL_SECONDS
        );
    }
}

5.3 Why this approach is precise, not just convenient

Beyond avoiding the cost of a custom sweep job, native TTL support is also more precise. Because expiration is tracked per-record at the moment of write, rather than computed later by comparing a stored timestamp against the current time during a periodic scan, the storage engine can make expired data actually inaccessible essentially immediately once its TTL elapses — for Redis specifically, an access to an expired key is checked and rejected right at read time (lazy expiry), even before the background cleanup cycle has gotten around to physically removing it, so there’s no window where a client-facing read can return content past its intended lifetime.

5.4 Where the buffer between logical and physical deletion matters

It’s worth being precise about a subtlety here: “logically expired” (no client can retrieve it anymore) and “physically deleted” (the bytes are fully removed from disk) aren’t always the exact same instant, particularly for Cassandra-style tombstone-and-compaction deletion, where the physical removal happens during a later compaction cycle. This is generally an acceptable gap for this product’s purposes — what actually matters for the privacy promise is that no client can retrieve the content anymore, which native TTL support guarantees essentially immediately at the logical level, even if the very last physical bytes linger briefly on disk before compaction clears them.

Before a viewer can watch anyone’s story, the product needs to show them a lightweight indicator — typically a row of avatars — for which followed accounts currently have at least one active story. This is a smaller, gentler version of the fan-out problem tackled in depth in an earlier tutorial in this series, and it’s worth noticing both how it’s similar and how it’s genuinely different.

6.1 Why this is a much lighter fan-out problem than a content feed

A content feed fans out entire posts — potentially rich, heavy content — to potentially enormous follower counts, which is what made the celebrity-account fan-out problem covered elsewhere in this series so consequential. Here, the fan-out payload is tiny: just an indicator that “this account has an active story,” not the story content itself. Even for an account with an enormous follower count, updating a lightweight “has active story” flag for every follower is a dramatically cheaper operation than fanning out full content — closer in spirit to a presence indicator than to a content distribution problem.

6.2 Letting the index expire on its own, using the same TTL principle

A particularly elegant aspect of this design: the active-story index entries can carry the exact same 24-hour TTL as the underlying story content itself. This means the “has active story” indicator disappears from a viewer’s story ring automatically, at the same moment the content itself becomes inaccessible, without any separate cleanup logic needing to explicitly reconcile the two — they’re kept in sync simply by using the same expiration mechanism for both, rather than by any custom logic checking one against the other.

// Updating the active-story index using the same TTL principle
// as the underlying content - kept in sync "for free"
public class StoryRingIndexer {

    private final RedisClient redis;
    private final FollowGraphClient graphClient;
    private static final Duration RING_TTL = Duration.ofHours(24);

    public void handleStoryCreated(StoryCreatedEvent event) {
        Iterator<String> followerIds = graphClient.getFollowersStream(event.getAuthorId());

        List<String> batch = new ArrayList<>();
        while (followerIds.hasNext()) {
            batch.add(followerIds.next());
            if (batch.size() == 500) {
                markActiveForBatch(batch, event.getAuthorId());
                batch.clear();
            }
        }
        if (!batch.isEmpty()) {
            markActiveForBatch(batch, event.getAuthorId());
        }
    }

    private void markActiveForBatch(List<String> followerIds, String authorId) {
        try (Pipeline pipeline = redis.openPipeline()) {
            for (String followerId : followerIds) {
                String key = "ring:" + followerId;
                // Sorted set per viewer: member = author, score = expiry time.
                pipeline.zadd(key, System.currentTimeMillis() + RING_TTL.toMillis(), authorId);
            }
            pipeline.sync();
        }
    }
}

// Reading the ring - trimming anything whose "expiry score" has passed,
// since a sorted set itself doesn't natively expire individual members
public class StoryRingReader {

    private final RedisClient redis;

    public List<String> getActiveRing(String viewerId) {
        String key = "ring:" + viewerId;
        long now = System.currentTimeMillis();
        redis.zremrangeByScore(key, 0, now);
        return redis.zrevrange(key, 0, -1);
    }
}

Notice the second code sample handles a subtlety worth calling out explicitly: unlike a plain key with an EXPIRE set on it, individual members of a sorted set don’t natively expire on their own in most implementations. The pattern shown — storing an explicit expiry timestamp as the score, and trimming anything past that score on read — approximates the same self-expiring behavior at the individual-member level, which the underlying data structure doesn’t directly provide. This is a good example of adapting the TTL principle established in the previous section to a situation where the most convenient data structure for the access pattern (a sorted set, needed for efficient “get this viewer’s whole ring” queries) doesn’t happen to offer that exact native capability at the granularity needed.

Story creators typically want to know who has viewed their story, and viewers themselves need the app to remember which stories they’ve already seen, so the story ring can visually distinguish “new, unwatched” from “already watched” content. Both of these are variations on the viewer-tracking problem covered in much greater depth in an earlier tutorial in this series, adapted here to the 24-hour time boundary.

7.1 Why exact tracking, not approximate counting, is usually the right choice here

The earlier profile-view tracking system in this series leaned heavily on approximate counting (HyperLogLog) specifically because it needed to track potentially enormous, ever-growing distinct-viewer counts efficiently over long or unbounded time windows. Here, the situation is different in a way that changes the right answer: a given story’s viewer count is bounded both in time (only 24 hours) and, realistically, in scale (a typical story’s audience is the poster’s follower count, rarely approaching the extreme scale that made approximate counting so valuable in that earlier system). For the large majority of stories, an exact, small, capped viewer list is both perfectly affordable and more useful to the product than an approximate count would be, since users specifically want to know who viewed their story, not just an estimated count.

// Exact viewer tracking, TTL-bound to match the story's own lifetime
public class StoryViewTracker {

    private final RedisClient redis;

    public void recordView(String storyId, String viewerId, Duration remainingTtl) {
        String key = "views:" + storyId;
        // A set naturally deduplicates - a viewer watching the same
        // story twice doesn't inflate the count or list.
        redis.sadd(key, viewerId);
        // Align this set's TTL with the story's own remaining lifetime,
        // so viewer data never outlives the content it describes.
        redis.expire(key, remainingTtl);
    }

    public long getViewCount(String storyId) {
        return redis.scard("views:" + storyId);
    }

    public Set<String> getViewerList(String storyId) {
        return redis.smembers("views:" + storyId);
    }
}

Notice the TTL applied here is deliberately tied to the story’s own remaining lifetime, computed at write time — not a fresh, independent 24-hour TTL — so that viewer data can never outlive the content it describes, even if a view happens to be recorded close to the story’s original expiration moment.

7.2 Handling exceptionally large audiences without abandoning exactness entirely

For the comparatively rare account whose story genuinely does receive an enormous number of views — a large media account or a celebrity-scale profile — a plain, unbounded set could grow large enough to become a genuine memory concern within its 24-hour lifetime. Here, a sensible hybrid mirrors the same eager/lazy thinking used elsewhere in this tutorial series: continue tracking an exact, capped list of the most recent viewers (useful for the product’s “recently viewed by” UI, which realistically only ever displays a handful of names anyway) while switching to an approximate HyperLogLog-based count specifically for the aggregate number once viewer volume crosses a reasonable threshold — the same exact-list-plus-approximate-count pattern used in the profile-view tracking system, just applied here only above a threshold, rather than universally.

7.3 Seen-state tracking, from the viewer’s own perspective

Separately from the creator wanting to know who viewed their story, each viewer’s own client needs to remember which specific stories they’ve already watched, so the story ring can render a visual “already seen” versus “new” distinction. This is naturally modeled as a small, per-viewer set of story IDs they’ve watched, also TTL-bound to expire alongside the stories it references — there’s no reason for a viewer’s “already seen” record for a specific story to persist any longer than the story itself remains relevant.

9.1 Why the TTL is set at write time, not computed at read time

A tempting but weaker alternative design stores a plain created_at timestamp and computes, on every single read, whether now - created_at > 24 hours. This works correctly, but it pushes the expiration logic into every single piece of application code that ever reads a story, and — critically — it doesn’t give the storage layer itself any way to actually reclaim space or stop serving genuinely expired data on its own; it’s just a filter applied after the fact by application code, which still has to fetch (or at least look at) the technically-expired record to determine that it should be treated as gone. Setting the TTL directly at write time, using the storage engine’s native mechanism, moves this decision into the layer best equipped to enforce it efficiently and consistently, exactly as argued in the dedicated TTL section.

9.2 Grouping multiple stories from one user into a sequence

Users often post several stories within the same day, and the product typically presents them as one continuous, ordered sequence rather than several entirely separate pieces of content. This is handled simply by having each story carry its own independent creation timestamp and TTL, with the client (or a thin sequencing layer) ordering a given user’s currently-active stories by creation time at render time — there’s no need for a separate “story collection” entity with its own lifecycle, since the natural ordering and independent expiration of each individual story already produces the right sequencing behavior without additional bookkeeping.

9.3 Audience type and its interaction with expiration

The audience_type field (public, followers-only, a restricted “close friends” list) affects who can view a story, but deliberately doesn’t affect its expiration behavior — every story expires on the same 24-hour schedule regardless of audience restriction. Keeping these two concerns — access control and expiration — fully independent of each other in the data model avoids a whole category of subtle bugs that could otherwise arise from an audience-dependent expiration rule interacting unexpectedly with the TTL mechanics covered throughout this tutorial.

10.1 Why Redis, specifically, is such a strong fit for the majority of this system

Nearly every fast-moving, short-lived structure in this design — story metadata (if choosing Redis over Cassandra/DynamoDB for that layer), the ring index, viewer sets — shares a common shape: bounded lifetime, high read frequency, and a natural fit with Redis’s built-in data structures (sorted sets, plain sets, simple key-value with TTL). This mirrors a similar observation made in the profile-view tracking tutorial in this series, and it’s worth restating as a general pattern: whenever a system’s core data has a naturally bounded, relatively short lifetime and needs to be read very frequently, an in-memory, TTL-native store is very often the right default reach, rather than a durable, disk-backed system built with permanence as its core assumption.

10.2 When Cassandra or DynamoDB might be preferred over Redis for the primary story store

Despite Redis’s strong fit for most of this system, the primary story metadata store specifically might reasonably favor Cassandra or DynamoDB instead, for one important reason: durability expectations. Redis is fundamentally an in-memory store — even with persistence options enabled, it’s not always the first choice for data a product wants to guarantee survives a node failure without any risk of loss during the (admittedly short) 24-hour window that data needs to remain reliably available. Cassandra and DynamoDB, being disk-backed, distributed, and replicated by design, offer stronger durability guarantees for the primary content record, while a bounded, less strictly-durability-sensitive supporting structure like the ring index or viewer set can reasonably still live in Redis, accepting a small amount of additional risk in exchange for speed, since losing a viewer count briefly is a far smaller problem than losing the story content itself.

10.3 Blob storage lifecycle policies as a backstop, not the primary mechanism

Most object storage services support configuring an automatic deletion policy on objects after a specified duration, entirely independent of any application-level logic. Using this as a second, independent expiration mechanism for the actual media bytes — set to trigger shortly after the metadata layer’s own TTL — provides genuine defense in depth: even in a scenario where a bug caused the metadata layer’s TTL to somehow not fire correctly, the underlying bytes would still be removed on their own independent schedule, closing that gap rather than relying on a single point of enforcement for a requirement this important to the product’s core promise.

An earlier tutorial in this series built an entire caching philosophy around indefinite, aggressive caching, justified by content being genuinely immutable and permanent. This system needs almost the opposite discipline: caching still matters enormously for performance, but every cache lifetime needs to be explicitly bounded to respect the content’s own expiration, never allowed to accidentally outlive it.

11.1 CDN cache TTL must never exceed content lifetime

When story media is served through a CDN, the cache-control headers governing how long an edge location may retain a cached copy need to be set conservatively relative to the content’s remaining lifetime — commonly by setting an explicit expiration time (rather than a simple max-age duration) that matches the story’s own known 24-hour cutoff, so that even a PoP that cached the content near the very start of its life doesn’t inadvertently continue serving it past the moment it should have expired.

// Setting cache headers with an absolute expiration matching
// the story's own TTL, rather than a fixed relative max-age
public class StoryCacheHeaderBuilder {

    public void applyCacheHeaders(HttpResponse response, Story story) {
        Instant expiresAt = story.getCreatedAt().plus(Duration.ofHours(24));
        long secondsUntilExpiry = Duration.between(Instant.now(), expiresAt).getSeconds();

        if (secondsUntilExpiry <= 0) {
            response.setHeader("Cache-Control", "no-store");
            return;
        }

        // max-age reflects only the *remaining* lifetime, not a flat 24h,
        // since a request made 20 hours after posting should only be
        // cacheable for the 4 hours actually left, not a fresh 24h window.
        response.setHeader("Cache-Control", "public, max-age=" + secondsUntilExpiry);
        response.setHeader("Expires", HttpDateFormatter.format(expiresAt));
    }
}

Notice the deliberate detail in the code above: max-age is computed as the story’s remaining lifetime at request time, not a flat 24 hours applied to every request regardless of when it happens to occur. A request arriving 20 hours after posting should only be cacheable for the 4 hours genuinely remaining — caching it for a fresh 24-hour window at that point would directly violate the content’s actual expiration promise.

11.2 Why this system still benefits enormously from a CDN, despite the bounded caching

It might seem like the bounded, shrinking cache lifetime here makes a CDN less valuable than in the permanent-content case, but the opposite is largely true: stories see the overwhelming majority of their total views concentrated in the hours immediately following posting, while interest is freshest — precisely the period where a CDN’s caching benefit matters most. The cache lifetime shrinking as the story ages simply mirrors the content’s own naturally declining relevance and view volume over that same window, which is a reasonably good match rather than a poor one.

11.3 Client-side caching, with the same bounded discipline

Client applications caching recently-viewed story media locally need to respect the same expiration-aware headers, ensuring a device doesn’t continue rendering a locally-cached copy of a story from local storage past its actual expiration — the same standard HTTP caching semantics used elsewhere in this tutorial series apply directly here, just with a shrinking rather than effectively-infinite max-age value driving the behavior.

11.4 Metadata caching still follows the usual cache-aside pattern

Access-control and audience-type checks on story metadata still benefit from the same cache-aside pattern discussed for other systems in this series, since that data changes relatively rarely within a story’s short lifetime — just with the same TTL-alignment discipline applied consistently, so a cached metadata entry can never outlive the underlying TTL-native record it describes.

12.1 Partitioning by owner, consistent with the pattern used throughout this series

Story metadata, the ring index, and viewer sets all naturally partition by the relevant user ID — owner_id for story content and viewer sets scoped to a specific story’s creator, viewer_id for the ring index — following the same consistent-hashing-with-virtual-nodes approach used generally throughout this tutorial series, keeping the dominant per-user access patterns confined to single shards.

12.2 A distinctive sharding consideration — load naturally self-balances over each 24-hour cycle

Worth noting as a genuinely distinctive property of this system: because content continuously expires roughly as fast as new content arrives (as established in the capacity estimation section), the total amount of “live” data any given shard needs to hold stays relatively stable over time, rather than growing indefinitely the way a shard holding permanent content would. This means shard capacity planning here is less about “how much bigger will this shard need to get over the platform’s lifetime” and more about “does this shard’s steady-state size, given current traffic levels, fit comfortably within its allocated capacity” — a meaningfully simpler, more stable planning problem than the ever-growing shard sizes a permanent-content system has to account for.

12.3 Load balancing the Story Ring Service specifically

Given that story-ring fetches happen on essentially every app open (as reflected in the capacity estimation’s roughly five billion daily ring-fetch requests), this service needs generous, elastic horizontal scaling behind a standard load balancer, similar to the Feed Service in the earlier content-feed tutorial in this series — it’s one of the most frequently-hit read paths in the entire system, even though the underlying data it serves is comparatively lightweight.

12.4 Hot accounts and the same mitigation principle as elsewhere

An account with an unusually large follower count posting a story can still create a temporary hotspot on whichever shard holds that account’s ring-fanout workload, following the same pattern discussed for celebrity accounts and popular content throughout this tutorial series. The same general mitigation — detecting disproportionately large accounts and giving them dedicated capacity, or applying the pull-based threshold approach discussed in the story ring section — applies here just as it does elsewhere, simply at a smaller absolute scale given how lightweight this particular payload is.

GET /v1/story-ring HTTP/1.1
Authorization: Bearer <token>

Response 200 OK:
{
  "activeStories": [
    { "ownerId": "u_2201", "displayName": "Priya", "hasUnseen": true,
      "expiresAt": "2026-07-27T09:14:00Z" },
    { "ownerId": "u_5521", "displayName": "Marcus", "hasUnseen": false,
      "expiresAt": "2026-07-26T22:03:00Z" }
  ]
}

Notice the response includes an explicit expiresAt timestamp per entry, letting the client itself proactively remove an entry from the displayed ring the moment it passes, without necessarily waiting for the next full API refresh — a small but genuinely useful detail that keeps the UI feeling accurate to the underlying expiration guarantee even between polling intervals or push updates.

13.1 Why viewer list access is restricted at the API layer, not just hidden in the UI

Following the same access-control principle discussed for tiered features in the profile-view tracking tutorial in this series, the viewer-list endpoint should enforce ownership at the API layer itself — returning an authorization error for anyone other than the story’s owner — rather than relying on the client application to simply choose not to display that data to non-owners. An API that returns the data regardless of caller identity, trusting the client to withhold it appropriately, is not a genuine access control boundary at all.

13.2 Microservice boundaries mirror the distinct TTL-driven concerns

The Story Service (creation, primary content), Story Ring Service (lightweight fan-out), and Viewer Tracking Service are kept as distinct, independently-scalable services for reasons consistent with the general microservices reasoning used throughout this tutorial series — they have different load profiles (ring fetches happen far more often than story creation), different storage backends, and different durability requirements, and splitting them allows each to be scaled, deployed, and reasoned about independently.

14.1 Patterns worth naming explicitly

14.2 Anti-patterns to avoid

The overarching trade-off worth stating plainly: this design accepts additional configuration complexity — multiple, carefully-aligned TTL mechanisms across several storage and caching layers — specifically in exchange for a genuinely strong, technically-enforced privacy guarantee, rather than relying on a simpler but weaker approach (like a periodic sweep job) that would be easier to build but offer meaningfully less precise, less reliable expiration.

15.1 A trade-off worth naming honestly — engineering rigor versus the appearance of simplicity

It would be easy to present this tutorial’s design as an obviously correct, unambiguous improvement over a simpler sweep-based alternative in every respect, but that framing undersells a genuine cost worth acknowledging directly. Wiring native TTL support consistently through several distinct storage and caching layers, keeping them all aligned to the same source of truth, and building dedicated monitoring specifically for expiration precision, is meaningfully more upfront engineering investment than a single, centralized sweep job that a team could reason about by reading one piece of code in one place. The sweep-based approach’s weaknesses only become genuinely costly at real scale — for a team building this feature for the first time on a small platform, it’s entirely reasonable to start simpler and deliberately plan a migration toward the more robust, TTL-native architecture covered throughout this tutorial only once actual growth and real production experience justify the additional complexity, rather than over-engineering for a scale the product hasn’t reached yet.

16.1 Horizontal scaling, consistent with the rest of this tutorial series

Every stateful component here scales horizontally following the same consistent-hashing-based sharding principles applied throughout this series — more Redis shards, more Cassandra/DynamoDB capacity, and more Story Ring Service instances as traffic grows, with the genuinely distinctive advantage, established in the capacity estimation section, that total resident data volume stays roughly stable rather than growing indefinitely alongside platform age.

16.2 Why native TTL support is also a meaningful performance win, beyond correctness

It’s worth restating a point from the dedicated TTL section through a pure performance lens: a sweep-based deletion approach doesn’t just risk imprecision, it also imposes a real, continuously growing computational cost as content volume increases, since each sweep cycle has to examine an ever-larger dataset. Native TTL support avoids this scaling problem entirely — expiration cost is handled incrementally by the storage engine’s own internal mechanisms (lazy checks, tombstones and compaction, background scanning decoupled from application-visible capacity) rather than through a separate, increasingly expensive batch operation that competes with normal read/write traffic for resources.

16.3 Read-path optimization for the story ring specifically

Given how frequently the story ring is fetched (as established in the capacity estimation section, on the order of billions of requests daily), keeping this specific read path as lightweight as possible matters enormously — the sorted-set-based approach shown in the ring section, returning a compact list of active accounts with minimal per-entry data, is deliberately kept far leaner than the equivalent feed-assembly work covered in the content-feed tutorial in this series, precisely because it’s called so much more frequently per user session.

16.4 Batch fanout, applied at the smaller scale relevant here

The same batching and pipelining techniques used for feed fan-out in an earlier tutorial apply directly to the ring-index fanout shown in this tutorial’s code samples — batching writes and using pipelined commands rather than one-at-a-time network round trips, even though the absolute follower counts involved here are typically far smaller than the celebrity-scale numbers that made batching essential in that earlier system.

17.1 Where this system sits on the CAP spectrum

Consistent with most systems throughout this tutorial series, this design leans AP — favoring availability over strict consistency for the large majority of operations. A story ring that’s a few seconds stale, or a viewer count that hasn’t fully caught up with the very latest view, are both acceptable imperfections in exchange for the system remaining available and responsive.

17.2 A genuinely distinctive nuance — availability and expiration can occasionally pull in different directions

Worth naming explicitly, since it’s a nuance specific to this system among those covered in this tutorial series: there’s a subtle tension between “favor availability” and “guarantee timely expiration.” If a storage replica has been temporarily partitioned from the rest of the cluster and reconnects after some delay, it might serve a story that should have already expired according to the TTL, simply because that replica’s clock or replicated state briefly lagged behind. This doesn’t undermine the AP-leaning default established throughout this series, but it does mean the expiration guarantee, like every other consistency guarantee in an AP-leaning system, is itself eventually consistent rather than instantaneously and universally enforced the microsecond the TTL elapses across every single node globally.

17.3 Replication for durability, especially for the primary content store

As discussed in the storage systems section, the primary story metadata store benefits from the same kind of multi-replica durability protection used throughout this tutorial series — losing a story before its natural expiration due to an infrastructure failure is a real, visible product failure, distinct from and arguably worse than the acceptable staleness tolerated elsewhere in an AP-leaning design.

17.4 Graceful degradation specific to this system

• If the Story Ring Service is degraded, the app can fall back to showing a simpler, less personalized indicator (or briefly showing no ring at all) rather than failing entirely, following the same graceful-degradation principle used for ranking and other secondary concerns elsewhere in this tutorial series.
• If the Viewer Tracking Service is degraded, story viewing itself is entirely unaffected — a viewer can still watch a story even if their view fails to be recorded, since view recording is explicitly asynchronous and non-blocking, as established in the APIs section.
• If a specific storage shard holding ring or viewer data experiences a temporary partition, the affected functionality degrades gracefully to a smaller, isolated blast radius rather than the whole system becoming unavailable, consistent with the general sharding-and-isolation principles used throughout this tutorial series.

Privacy is arguably even more central to this feature’s core value proposition than most others covered in this tutorial series — the entire product premise is built around a promise that content genuinely disappears, and every security consideration here ultimately traces back to protecting that specific promise.

18.1 Audience restriction, independent of but as important as expiration

Beyond the time-based expiration this tutorial focuses on heavily, stories typically support audience restrictions — followers-only, a curated “close friends” subset, or fully public — enforced through the same kind of authorization checks discussed for private content in the earlier photo-sharing tutorial in this series, including signed, time-limited URLs for accessing story media, so that even a leaked direct link carries a bounded exposure window, consistent with that earlier tutorial’s approach.

18.2 Preventing unauthorized capture — an inherently limited but still worthwhile mitigation

Products in this space often attempt to detect or discourage a viewer taking a screenshot or screen recording of ephemeral content, notifying the creator when this happens. It’s worth being honest about the actual security properties here: this is fundamentally a best-effort, client-side detection mechanism, not a robust technical guarantee — a sufficiently motivated viewer can generally capture on-screen content through means the app has no visibility into (a second device’s camera, for instance), and platforms are generally upfront that this is a deterrent and transparency signal rather than an ironclad prevention mechanism.

18.3 Replay and re-sharing considerations

Because story media itself is technically just another blob object during its active window, a viewer’s client necessarily has the bytes available locally while viewing, which means preventing re-sharing or redistribution is, similarly to screenshot prevention, fundamentally limited by what a client-side application can enforce. Platforms typically address this primarily through product policy and terms of service rather than pretending a purely technical guarantee against redistribution is achievable once content has been rendered on a viewer’s device.

18.4 Ensuring deleted content doesn’t leak through backups or logs

A subtlety worth calling out explicitly: standard infrastructure practices elsewhere in a platform — database backups, application logs that might incidentally capture request payloads, analytics pipelines — can inadvertently retain a copy of content or metadata that the primary system has otherwise correctly expired, undermining the deletion guarantee through a side channel the TTL mechanisms discussed throughout this tutorial don’t touch. A genuinely rigorous implementation needs explicit retention policies for backups and logs involving this content, generally keeping raw content out of general-purpose logging entirely and applying a comparably short retention window to any necessary backups of the primary content store.

18.5 Content moderation, on a compressed timeline

Automated content moderation scanning, covered in general terms in the earlier photo-sharing tutorial, needs to operate quickly here specifically because the content’s entire viewing window is short — a moderation process that takes hours to flag policy-violating content is considerably less useful for a piece of content that’s only visible for 24 hours in the first place, compared to the same delay for permanent content that will remain reviewable indefinitely. This timing pressure is worth taking seriously as a genuine design constraint in its own right, not merely a minor inconvenience: a moderation pipeline tuned for a permanent-content platform’s more relaxed timeline, where a flagged post can be reviewed and removed days later with little lost value in catching it late, needs real rearchitecting to meet this system’s much tighter effective deadline, where the majority of a story’s total viewing activity may well have already happened before a slower moderation process would even have finished its review.

19.1 The metric unique to this system — expiration precision itself

Beyond the usual latency and error-rate metrics common across every system in this tutorial series, this design benefits from a metric that doesn’t have a close analog elsewhere: directly measuring the gap between a story’s intended expiration time and the moment it actually became inaccessible across each layer (primary store, ring index, CDN cache). Sampling a set of recently-expired stories and confirming they’re genuinely inaccessible everywhere, promptly, turns the core privacy promise from an assumption into something actively, continuously verified in production.

19.2 Alerting on expiration drift specifically

A dedicated alert triggering if the observed gap between intended and actual expiration exceeds a defined tolerance (informed by the same kind of “small, bounded imprecision is acceptable” reasoning established in the TTL and CAP sections) is worth having as a standing, ongoing safeguard — this is the one metric in this entire system where a regression has real, direct privacy consequences for users, not merely a performance inconvenience, which justifies a lower alerting threshold and faster required response than a typical latency regression would warrant elsewhere in the platform.

19.3 Standard pipeline health metrics, applied here as elsewhere

• Story-ring fetch latency (p50/p95/p99) — given how frequently this endpoint is called, even small regressions are felt broadly across the platform’s core browsing experience, mirroring the same emphasis placed on feed-open latency in the content-feed tutorial in this series.
• Ring-fanout event processing lag — a growing backlog here means newly-posted stories take longer than intended to appear in followers’ rings, delaying the product’s core “see what’s new” promise.
• Storage volume, tracked as a steady-state metric rather than a growth trend — unlike the ever-increasing storage growth charts relevant to a permanent-content system, a healthy version of this system should show storage volume oscillating around a relatively stable baseline; a sustained upward drift here is itself worth investigating, since it may indicate a TTL misconfiguration causing content to linger longer than intended, rather than simply reflecting expected platform growth.

19.4 Distributed tracing across the creation-to-expiration lifecycle

A trace ID following a single story from creation through ring fanout, viewing, and eventual expiration — the same distributed tracing principle applied to other multi-service pipelines throughout this tutorial series — makes it possible to diagnose specific questions like “why did this particular story remain visible slightly past its intended expiration” by following its actual path through every layer, rather than reconstructing the timeline from disconnected logs after the fact.

20.1 Standard containerized deployment, following the pattern used throughout this series

The Story Service, Story Ring Service, and Viewer Tracking Service all follow the same containerized, orchestrator-managed deployment pattern used consistently across every system in this tutorial series, each scaling independently based on its own relevant load signal.

20.2 Multi-region deployment, with an added TTL-consistency consideration

Beyond the usual reasoning for multi-region deployment — reducing latency for a geographically distributed user base, and providing resilience against a regional outage — this system has one additional wrinkle worth calling out: if story metadata is replicated across regions, clock skew or replication lag between regions could theoretically cause a story to appear to expire at slightly different moments in different regions, depending on which replica a given request happens to be served from. Using a consistent, well-synchronized time source for computing TTLs (rather than relying on each individual region’s local clock independently) and keeping the same small-tolerance mindset established throughout this tutorial helps keep this variance within the same acceptable bounds discussed in the CAP theorem section, rather than letting it grow into a more noticeable inconsistency.

20.3 CI/CD for TTL-related configuration changes specifically

Given how directly TTL configuration ties to this product’s core privacy promise, changes to TTL values, expiration logic, or cache-header computation deserve particularly careful, gradual rollout — a canary deployment validated against the same kind of synthetic expiration-verification monitoring discussed in the observability section, rather than trusting standard functional tests alone to catch a subtle regression in exactly how long content actually remains accessible.

20.4 Regional CDN configuration consistency

Because cache-control headers are computed once by origin infrastructure but interpreted independently by many geographically distributed CDN edge nodes, ensuring consistent CDN configuration across all regions — the same expiration-respecting header logic applied uniformly everywhere, rather than region-specific configuration drift — is an important, easy-to-overlook operational discipline specific to this system’s privacy-sensitive caching requirements.

21.1 Disaster recovery, with a genuinely unusual twist

Most disaster recovery discussions in this tutorial series focus on ensuring data survives an infrastructure failure without loss. Here, there’s a real, worth-naming tension: standard disaster recovery practice (frequent backups, cross-region replication) protects content from being lost prematurely, but this product’s core promise is that content should stop existing after 24 hours regardless — meaning disaster recovery planning here needs to protect against premature loss during a story’s active window, while very deliberately not accidentally extending content’s life past its intended expiration through an overly aggressive backup or recovery process.

21.2 Backup strategy, scoped tightly to the content’s own short lifetime

Given how short-lived the primary content is, traditional long-retention backup strategies (daily snapshots kept for 30 days, as discussed for permanent-content systems in earlier tutorials) don’t make sense to apply uniformly here — a backup of story metadata should itself carry a comparably short retention window, consistent with the content it protects, rather than inadvertently creating a longer-lived shadow copy of content the product explicitly promises will disappear. Any exception to this — the compliance retention store discussed in the security section — needs to be a deliberate, clearly separated, access-restricted system, not an accidental byproduct of applying a generic backup policy without adjustment.

21.3 Cost optimization — a genuinely different profile than the permanent-content case

• No storage tiering needed for the primary content — as established in the storage systems section, nothing here persists long enough to justify migrating to progressively cheaper cold-storage tiers, which meaningfully simplifies (and reduces the cost of) the storage architecture compared to a permanent-content platform.
• Compression still matters, just over a shorter total lifetime — efficient media compression reduces both storage footprint during the active window and CDN bandwidth cost, following the same reasoning as the earlier photo-sharing tutorial, just amortized over a much shorter content lifetime.
• Right-sizing capacity around a stable steady state, not a growth curve — because total data volume stays roughly constant rather than growing indefinitely, capacity planning can focus on current traffic levels and near-term user growth, rather than needing to provision years of accumulating headroom the way a permanent-content system’s storage tier does.
• CDN cost naturally scales down as content ages — since cache lifetime shrinks as a story approaches its expiration (as covered in the caching section), the system doesn’t pay for extended, low-value caching of content nearing the end of its relevance, aligning cost with actual likely future demand reasonably well.

22.1 How Redis actually implements TTL internally

It’s worth understanding the actual mechanism behind Redis’s expiration behavior, since interviewers often probe past “just call EXPIRE” into how it really works. Redis uses two complementary strategies simultaneously. Lazy expiration checks a key’s expiry timestamp at the moment it’s actually accessed — if a read or write touches a key whose TTL has passed, Redis treats it as if it doesn’t exist and removes it right then, guaranteeing no client can ever retrieve genuinely expired data, regardless of whether background cleanup has gotten to it yet. Active expiration runs as a periodic background cycle that samples a small number of keys with TTLs set, removing any that have expired, specifically so that keys which are never accessed again after expiring don’t simply sit in memory forever — without this second mechanism, a key nobody ever reads again after its TTL passes would never actually get cleaned up through the lazy path alone, since that path only triggers on access.

// A simplified illustration of the two-part expiration strategy -
// production Redis is considerably more optimized, but this
// captures the essential dual mechanism.
public class SimplifiedTTLStore {

    private final Map<String, String> data = new HashMap<>();
    private final Map<String, Long> expiryTimestamps = new HashMap<>();

    public void set(String key, String value, Duration ttl) {
        data.put(key, value);
        expiryTimestamps.put(key, System.currentTimeMillis() + ttl.toMillis());
    }

    // Lazy expiration: check on every read, regardless of background cleanup
    public Optional<String> get(String key) {
        if (isExpired(key)) {
            removeKey(key);
            return Optional.empty();
        }
        return Optional.ofNullable(data.get(key));
    }

    // Active expiration: periodically sample and remove expired keys,
    // so unread expired keys don't linger indefinitely in memory
    public void runActiveExpirationCycle(int sampleSize) {
        List<String> sample = sampleRandomKeys(expiryTimestamps.keySet(), sampleSize);
        for (String key : sample) {
            if (isExpired(key)) {
                removeKey(key);
            }
        }
    }

    private boolean isExpired(String key) {
        Long expiry = expiryTimestamps.get(key);
        return expiry != null && System.currentTimeMillis() > expiry;
    }

    private void removeKey(String key) {
        data.remove(key);
        expiryTimestamps.remove(key);
    }

    private List<String> sampleRandomKeys(Set<String> keys, int count) {
        List<String> list = new ArrayList<>(keys);
        Collections.shuffle(list);
        return list.subList(0, Math.min(count, list.size()));
    }
}

22.2 Timing wheels — a more advanced structure for scheduling precise, high-volume expirations

For systems that need to schedule and precisely trigger a very large number of time-based events efficiently — which describes this system’s expiration needs well, given millions of stories expiring continuously throughout each day — a timing wheel is a genuinely useful data structure worth knowing, used internally by several high-performance networking and scheduling systems. The idea: organize scheduled events into a circular buffer of time “buckets,” where each bucket represents a small time interval, and an event is placed into the bucket corresponding to when it should fire. A single pointer advances around the wheel over time, and whenever it reaches a bucket, every event scheduled in that bucket fires. This achieves close to constant-time insertion and firing, dramatically more efficient than repeatedly scanning a large, unsorted list of pending expiration times to find what’s due next.

// A simplified timing wheel for scheduling expiration callbacks
public class TimingWheel {

    private final List<List<Runnable>> buckets;
    private final int bucketDurationMillis;
    private int currentBucket = 0;

    public TimingWheel(int numBuckets, int bucketDurationMillis) {
        this.bucketDurationMillis = bucketDurationMillis;
        this.buckets = new ArrayList<>();
        for (int i = 0; i < numBuckets; i++) {
            buckets.add(new ArrayList<>());
        }
    }

    public void scheduleExpiration(Runnable onExpire, long delayMillis) {
        int ticksAhead = (int) (delayMillis / bucketDurationMillis);
        int targetBucket = (currentBucket + ticksAhead) % buckets.size();
        buckets.get(targetBucket).add(onExpire);
    }

    // Called by a driving clock/scheduler on each tick of the wheel
    public void advanceTick() {
        List<Runnable> dueNow = buckets.get(currentBucket);
        for (Runnable callback : dueNow) {
            callback.run(); // fire the expiration action
        }
        dueNow.clear();
        currentBucket = (currentBucket + 1) % buckets.size();
    }
}

This is a genuinely useful structure to be aware of conceptually, even though this tutorial’s primary recommendation remains leaning on a storage engine’s own native TTL support (as covered at length in the dedicated TTL section) rather than building custom scheduling infrastructure from scratch — the timing wheel is, not coincidentally, very similar in spirit to the kind of mechanism a storage engine’s own internal active-expiration cycle is likely built on. Understanding it helps explain why native TTL support scales as well as it does, rather than treating it as an unexplained black box.

22.3 Comparing expiry mechanisms side by side

22.4 Why this section matters beyond passing an interview question

It’s worth stepping back and noting why understanding these mechanisms at this level of depth actually matters in practice, not just as interview trivia. A team that understands lazy versus active expiration, and why a timing wheel scales the way it does, is much better equipped to reason correctly about the actual guarantees their chosen storage engine provides — and, just as importantly, about where those guarantees have edges. Knowing that active expiration works probabilistically, by sampling, rather than by exhaustively checking every expired key on every cycle, for instance, helps explain why a very small number of expired-but-unaccessed keys might occasionally persist slightly longer than expected in memory even with native TTL support fully enabled, which is exactly the kind of nuance that separates confidently using a tool correctly from merely knowing its name.

23.1 Best practices worth internalizing

The following practices generalize well beyond this specific feature, and are worth carrying into any system where time-bounded correctness genuinely matters.

• Always reach for a storage engine’s native expiration support first. This is the single most important, broadly-applicable lesson from this entire tutorial — custom expiration logic is very rarely a better choice than a well-established storage engine’s own built-in mechanism.
• Derive dependent structures’ TTLs from the same source of truth, rather than giving each one an independently-computed expiration that could drift out of sync with the content it describes.
• Treat expiration precision as a monitored, alertable metric in its own right, not an assumption you build once and trust indefinitely without verification.
• Match caching aggressiveness to content lifetime explicitly, rather than defaulting to caching patterns designed for permanent content.
• Build defense-in-depth for deletion specifically, given the real privacy consequences of getting this particular guarantee wrong, following the layered approach (metadata TTL plus independent blob lifecycle policy) covered throughout this tutorial.

23.2 Common mistakes

The following patterns show up repeatedly enough across real implementations of this kind of feature that they’re worth naming explicitly, so they can be caught during design review rather than discovered later in production.

• Reaching for a periodic sweep job as the primary expiration mechanism, rather than a storage engine’s native TTL support, leading to both weaker precision and worse scaling characteristics as data volume grows.
• Applying a permanent-content caching philosophy without adjustment, risking content remaining accessible past its intended expiration through an overly long cache lifetime.
• Letting the ring index or viewer tracking structures use independent, disconnected TTLs rather than deriving them from the underlying content’s own remaining lifetime, risking visible inconsistency between what the product shows and what’s actually still valid.
• Forgetting that standard infrastructure practices — logging, backups — can inadvertently undermine the deletion guarantee through a side channel the primary TTL mechanisms never touch.
• Treating screenshot or capture prevention as a robust technical guarantee rather than the inherently limited, best-effort deterrent it actually is.

This is best modeled as an explicit, separate copy operation rather than an exception carved into the ephemeral system’s own expiration logic. When a user chooses to save a story to a permanent collection, the system creates a new, independent, non-expiring record (following the permanent-content patterns from the earlier photo-sharing tutorial in this series) referencing the same underlying media, rather than trying to selectively cancel or extend the original ephemeral record’s TTL — keeping the ephemeral and permanent storage paths cleanly separated avoids a whole category of complexity that would arise from trying to make one system serve both fundamentally different lifetime requirements.

Overwhelmingly, from posting — every viewer sees the same story for the same window, ending 24 hours after the creator originally posted it, regardless of when any individual viewer happens to watch it. This is the far simpler and more common design, and it’s what every code sample and diagram throughout this tutorial assumes; a per-viewer expiration window would introduce considerably more bookkeeping (a separate expiration clock per viewer, per story) for a viewing model most platforms in this space haven’t found compelling enough to justify that added complexity.

The underlying TTL mechanism should always be computed and stored using an unambiguous, absolute time reference (UTC-based epoch time, as used throughout this tutorial’s code samples) rather than any timezone-relative representation — this sidesteps daylight saving and timezone ambiguity entirely, since “24 hours from this exact UTC instant” is a fully unambiguous, well-defined point in time regardless of which timezone any particular viewer happens to be in when they check.

Very directly — every mechanism covered in this tutorial (native TTL, ring-index alignment, bounded CDN caching) parameterizes cleanly on the expiration duration itself, and none of the core architectural decisions are actually tied to the specific number 24 hours. The one area worth reconsidering for a meaningfully longer window is the storage growth assumption from the capacity estimation section — a 7-day window means roughly seven times more steady-state resident data than a 24-hour window at the same posting rate, which is still bounded and non-accumulating, just at a proportionally larger stable baseline.

For a platform with modest scale and traffic, a single TTL-native store (Redis alone, without necessarily needing Cassandra or DynamoDB for additional durability) handling both metadata and the ring index, without a dedicated CDN layer, would likely perform perfectly well. The full depth covered in this tutorial — defense-in-depth deletion, careful multi-layer TTL alignment, dedicated expiration-precision monitoring — earns its complexity specifically at the millions-of-daily-views scale described in the original prompt, not as a baseline requirement for implementing this feature at any scale whatsoever.

Here’s the narrative worth being able to walk through cleanly, start to finish, if asked to design this system live.

Placed alongside the other systems in this tutorial series — a content feed built around fan-out economics, a profile-view tracker built around write-heavy aggregation, and a photo-sharing platform built around the physics of global content delivery — this ephemeral stories system rounds out the set with a distinctive lesson of its own: sometimes the dominant constraint shaping an entire architecture isn’t about serving more, or serving faster, but about reliably, precisely, and privately making something stop existing exactly when it’s supposed to.

That’s a genuinely useful lesson to carry forward well beyond this specific feature. Most system design discussions, and most real engineering work, focus naturally on how to build things that persist, scale, and serve traffic well — this tutorial’s central case study is a reminder that an equally rigorous, equally interesting engineering discipline exists on the other side of that coin: building systems that keep a precise, trustworthy promise about when and how something should stop existing, which turns out to demand just as much careful, deliberate design as building something meant to last forever.