Data Lifecycle — Example: Social Media Photo Post

The Scenario

A user takes a photo on their phone, types a caption, adds a location tag, and posts it to a social media platform. Their followers see it in their feeds. Some like it. One person comments. The post appears in search results. A week later, the user checks how many views it got.

This example is interesting because the data fans out — one input (a photo) creates dozens of downstream data flows touching many different parts of the system.

Step 1: Identify All the Data

The obvious:

• The photo file
• The caption text
• The location tag
• Likes
• Comments

The hidden:

A single photo post touches 15+ data categories.

Step 2: Full Lifecycle Map

Phase 1: Upload and Ingest

Phase 2: Distribution (Fan-Out)

Phase 3: Indexing

Phase 4: Engagement (Ongoing)

Phase 5: Analytics (Later)

Step 3: The Fan-Out Problem

This example reveals a pattern the other examples don't: fan-out.

When a user with 10,000 followers posts a photo, the system must:

• Create 10,000 feed entries (one per follower)
• Potentially send 10,000 notifications
• Handle 10,000 potential views, likes, and comments

This is a one-to-many transport and storage problem. The lifecycle of a single post multiplies at the distribution phase.

                                           ┌─ Follower A's feed
                                           ├─ Follower B's feed
    ┌──────┐       ┌────────┐              ├─ Follower C's feed
    │ Post │──────►│Fan-Out │──────────────├─ Follower D's feed
    │      │       │Service │              ├─ ...
    └──────┘       └────────┘              └─ Follower N's feed
                       │
                       │
                       ▼
                  ┌──────────┐             ┌─ Notification → A
                  │Notify    │─────────────├─ Notification → B
                  │Service   │             └─ Notification → (subset)
                  └──────────┘

This creates interesting data lifecycle questions:

• Do you create all 10,000 feed entries immediately? Or lazily when each follower opens their app?
• What if a follower opens their feed while the fan-out is still in progress? Do they see the post or not?
• What if the user deletes the post 5 seconds after posting? Can you recall all 10,000 feed entries?

These are design decisions that emerge directly from mapping the lifecycle.

Step 4: Multiple Storage Locations — Same Data

Notice that the same photo exists in multiple forms and multiple places:

Five copies of what started as one photo. Each has a different purpose and potentially a different lifecycle. If the user deletes the post, ALL five must be deleted — plus the CDN caches must be invalidated. Missing any one copy means orphaned data sitting in storage forever.

Step 5: Comparing All Three Examples

Key Takeaways From This Example

1. Fan-out multiplies the lifecycle — one action can create thousands of downstream data events
2. The same data exists in multiple forms — and each form has its own storage, its own lifecycle, and its own deletion requirements
3. Indexing is a separate lifecycle stage — making data searchable requires transforming and storing it in additional specialized formats
4. Privacy intersects with data lifecycle — EXIF stripping, privacy-filtered distribution, and blocked-user exclusion are all transforms driven by non-obvious data (privacy settings, block lists)
5. Analytics are derived data — not stored at the time of action, but aggregated later from atomic records (views, likes, comments)

When mapping a system where one action triggers many reactions, always ask: "How many copies of this data exist, and what happens to all of them when the original changes?"