Design a Mobile Loyalty App: Starbucks-Style Rewards

Mobile loyalty apps (Starbucks, Chipotle, Dunkin) are unusually rich mobile system design topics. They combine payment processing, loyalty points, mobile ordering, geofencing, and the realities of physical retail integration. The Starbucks app in particular has been studied for its size and engagement — over 30M monthly active users.

Functional requirements

  • Earn points (stars) for purchases
  • Pay with stored loyalty balance via QR/barcode
  • Mobile order ahead at a specific store
  • Customize drinks/items with options
  • Send/receive gift cards to friends
  • Find nearby stores with hours and inventory

Architecture

Three modules: store / catalog, order, loyalty.

Loyalty mechanics

Each transaction adds points. Points have:

  • Earning rules (purchase amount, item type, time of day)
  • Tier system (free → reward levels)
  • Expiration (points expire after N months)
  • Promotion events (double-points day, bonus stars)

Server is authoritative — never let the client decide point balance.

Mobile payment

The Starbucks model: prepaid stored value. User loads $X via credit card; in-store, present QR code; system deducts from stored value.

Benefits to the company: float (held customer cash), reduced credit card fees per transaction, increased switching cost.

Implementation:

  1. User reloads stored value via credit card (real Stripe/Adyen call)
  2. Balance updates server-side
  3. Client shows balance
  4. In-store: app generates QR with token tied to the user account + brief expiry
  5. POS scans QR; server deducts

Mobile order ahead

User picks a store, customizes order, pays, app provides estimated pickup time.

Architecture:

  1. Client requests menu for the chosen store
  2. User customizes order
  3. Client submits order with idempotency key
  4. Server validates inventory and pricing
  5. Charges loyalty balance + reload if needed
  6. Server pushes order to in-store POS
  7. Server returns estimated ready time

Geofencing: when user is N miles from the store, app pushes notification. When they arrive, the order moves to the front of the queue.

Customization engine

Drinks have many options. Modeling:

  • Base item (Latte)
  • Modifiers (size, milk, syrup, espresso shots)
  • Per-modifier price adjustments
  • Calorie / nutrition impact

This is data modeling — custom orders need a flexible schema with strong validation.

Offline behavior

  • Show last-known balance with “as of [time]”
  • QR code generation works offline (cached token with longer expiry)
  • Mobile order requires network (cannot place an order to a store without confirmation)

Push notifications

  • Order ready
  • Promotional offers
  • Nearby store reminders
  • Reward milestone reached

Push tokens stored per device. Throttle promotional pushes to avoid annoyance.

Frequently Asked Questions

How does the QR for in-store payment work?

Token-based. App generates a short-lived (5–10 minute) token tied to the user. Cashier scans QR; POS calls server to validate and deduct. Token cannot be replayed.

Why do loyalty apps push so many notifications?

Engagement metric. App teams are typically scored on DAU/MAU. Aggressive push tends to inflate metrics short-term but creates churn long-term. Balance is hard.

How is mobile order ahead synchronized with the in-store kitchen?

Orders push to a kitchen display system over a real-time channel. Status updates flow back as orders progress.

Scroll to Top