Data Lifecycle — Example: Coffee Shop Ordering

The Scenario

A customer orders coffee from a mobile app. They browse the menu, customize a drink, pay, and receive their drink at the store. The barista sees the order on a screen. The customer gets a push notification when the drink is ready.

This seems simple. Let's map it and see how much data is actually involved.

Step 1: Identify All the Data

Obvious data:

• The customer's drink selection (item, size, modifications)
• The customer's payment information
• The store's menu
• The order itself
• The receipt

Less obvious data:

• The store's current inventory (do they have oat milk today?)
• Store hours and availability (is the store even open?)
• The customer's account info (name, payment methods on file, order history)
• Order status (placed → paid → in progress → ready → picked up)
• Timestamps (when was the order placed? when was it ready?)
• The queue position (how many orders are ahead of this one?)
• Estimated wait time
• Push notification delivery status (did the notification reach the phone?)

That's at least 13 pieces of data for a single coffee order. Most people would have named 3 or 4.

Step 2: Full Lifecycle Map

Step 3: Flow Diagram

┌─────────┐    load menu    ┌──────────┐   fetch    ┌──────────┐
│Customer  │ ◄───────────── │  Server  │ ─────────►│ Database │
│  App     │                │          │            │(menu,    │
│          │ ──────────────►│          │            │inventory)│
│          │   place order  │          │            └──────────┘
└─────────┘                 │          │
     ▲                      │          │──────────────►┌──────────┐
     │ push notification    │          │  charge card   │ Payment  │
     │                      │          │◄──────────────│ Provider │
     │                      │          │  confirmation  └──────────┘
     │                      │          │
     │                      │          │──────────────►┌──────────┐
     │                      │          │  send order    │  Store   │
     │                      │          │◄──────────────│ Display  │
     │                      │          │  mark ready    └──────────┘
     │                      │          │
     │                      │          │──────────────►┌──────────┐
     │                      │          │  log events    │Analytics │
     │                      └──────────┘               └──────────┘
     │                           │
     │                           │ send notification
     │                      ┌──────────┐
     └──────────────────────│  Push    │
                            │ Service  │
                            └──────────┘

Step 4: Hidden Data Analysis

Let's call out the hidden data specifically:

That last row is interesting — it's data that doesn't exist in most systems but should, which is something you'd only discover by doing this analysis.

Step 5: What Could Go Wrong (by Lifecycle Stage)

Compare and Contrast: What This Example Teaches

This example demonstrates:

1. A "simple" system has 27+ data stages — complexity hides in the details
2. Multiple external services (payment provider, notification service, store display) each introduce transport risks
3. State management is critical — the order status flows through 5 states, and getting out of sync at any point creates visible bugs
4. Hidden data (metadata, config, logs) is as important as the obvious data — timestamps, tax rates, and delivery receipts make or break the system's debuggability
5. Failure at any stage has different consequences — some failures are cosmetic, some lose money, some lose customers

When you encounter the test questions, map them at this level of detail. If your lifecycle map has 5 stages, you probably missed 20.