↓Skip to main content
  1. System Design Components/

Read-Path NFR Cheat Sheet

Read-Path NFR Cheat Sheet #

Use this as a default starting point when specifying NFRs for read paths. These are baseline assumptions, not universal rules. Always refine them by product semantics and the specific path.

1. Source Detail Read #

Examples:

  • view profile
  • view current document
  • read current order state
  • read current booking

Default NFRs:

  • consistency: strong or at least read-your-write for the acting user
  • latency: low interactive latency
  • availability: high
  • durability: not applicable for read path
  • freshness: should reflect current source truth or be very close to it

2. Relation List Read #

Examples:

  • followers/following
  • tagged items for a tag
  • files shared with me
  • current subscriptions

Default NFRs:

  • consistency: source relation truth should be fairly fresh; read-your-write often desirable for the acting user
  • latency: low to moderate interactive latency
  • availability: high
  • durability: not applicable for read path
  • freshness: should be close to source truth; minor lag may be acceptable depending on product

3. Workflow Status Read #

Examples:

  • track order status
  • track refund
  • track booking state
  • view ride/trip state

Default NFRs:

  • consistency: strong
  • latency: low to moderate interactive latency
  • availability: high
  • durability: not applicable for read path
  • freshness: should reflect current workflow state; stale lifecycle reads can confuse users and business logic

4. Inventory / Availability Read #

Examples:

  • seat map
  • room availability
  • stock availability
  • appointment slot availability

Default NFRs:

  • consistency: often bounded-stale is acceptable for browsing, but commit paths must revalidate strongly
  • latency: low to moderate interactive latency
  • availability: high
  • durability: not applicable for read path
  • freshness: seconds-level lag may be acceptable for browse, but not for commit validation

5. Search Read #

Examples:

  • document search
  • business search
  • profile search
  • hashtag search

Default NFRs:

  • consistency: eventual
  • latency: low interactive latency
  • availability: high
  • durability: not applicable for read path
  • freshness: bounded lag is usually acceptable, from seconds to minutes depending on product

6. Feed Read #

Examples:

  • home feed
  • subscriptions feed
  • activity feed
  • notifications feed

Default NFRs:

  • consistency: eventual
  • latency: low interactive latency
  • availability: very high, should degrade gracefully
  • durability: not applicable for read path
  • freshness: seconds-level lag often acceptable; exact freshness is product-specific

7. Top K / Trending / Ranking Read #

Examples:

  • trending hashtags
  • top restaurants
  • top creators
  • leaderboard

Default NFRs:

  • consistency: eventual
  • latency: low to moderate interactive latency
  • availability: high
  • durability: not applicable for read path
  • freshness: lag is acceptable, often tens of seconds to minutes

8. Dashboard / Reporting Read #

Examples:

  • admin reporting
  • finance dashboard
  • usage analytics
  • operations views

Default NFRs:

  • consistency: eventual
  • latency: moderate, sometimes seconds are acceptable
  • availability: can degrade more independently than core product paths
  • durability: not applicable for read path
  • freshness: minutes or more may be acceptable

9. History / Timeline Read #

Examples:

  • version history
  • audit history
  • reminder history
  • auction bid history

Default NFRs:

  • consistency: often strong enough that committed historical records should appear reliably, though indexing can lag
  • latency: low to moderate interactive latency
  • availability: high
  • durability: history records themselves must be durable at write time; read path has no durability requirement
  • freshness: committed records should appear reasonably quickly; exact indexing lag depends on implementation

10. Local Snapshot / Control-Plane Read #

Examples:

  • feature flag evaluation
  • config lookup on serving node
  • API key validation from local snapshot
  • policy evaluation from local evaluator cache

Default NFRs:

  • consistency: bounded-stale, version-controlled
  • latency: very low, often in-memory
  • availability: very high
  • durability: not applicable for read path
  • freshness: explicit propagation bound; monotonic version movement is critical

11. Realtime Stream Read #

Examples:

  • live comments
  • chat stream
  • watch/notification stream
  • live telemetry tail

Default NFRs:

  • consistency: usually eventual but ordered within a stream or partition when required
  • latency: very low, near-real-time target
  • availability: high, with graceful reconnect/replay behavior
  • durability: not applicable for live read path itself
  • freshness: sub-second to few-second lag target, depending on product

Quick Summary #

  • source detail / workflow reads: strong or very fresh
  • relation lists: fresh, sometimes source-backed
  • inventory browse: may be slightly stale, but commit must revalidate
  • search/feed/top-K/dashboard: usually eventual
  • local snapshot reads: bounded-stale, version-controlled
  • realtime streams: low-latency, usually eventually delivered with ordering constraints

Interview One-Liner #

For reads, I’d separate source-truth reads from projection reads: object and workflow status pages usually need strong or very fresh reads, while search, feeds, top-K, dashboards, and local snapshot evaluations can tolerate bounded staleness with explicit freshness targets.