Katkat
Back

Design a Configurable Reward Points Service

Bilt RewardsSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a highly available and auditable reward points service that ingests credit card and rent transactions, evaluates versioned earning rules, and maintains an append-only double-entry ledger.

Scenario

A modern loyalty and credit card platform rewards users for diverse transactions, such as residential rent, everyday dining, and travel bookings. The platform needs a dedicated Reward Points Service that ingests financial transaction events, evaluates dynamic and versioned earning rules (e.g., 3x on dining, 1x on rent with zero card fees, 5x during promotional Rent Day windows), credits points reliably, and supports point redemptions.

Because financial integrity and customer trust are critical, every point credited or spent must be fully explainable, idempotent, and backed by an immutable ledger.

Requirements

Functional Requirements

  1. Transaction Ingestion & Rule Evaluation: Ingest settled transactions and evaluate them against configurable, versioned point-earning rules.
  2. Explainable Ledger: Record point earnings and redemptions in an append-only ledger that preserves which rule version, multipliers, and caps produced the point total.
  3. Redemptions & Balance Checks: Allow users to query their current usable points balance and redeem points for travel, rent credits, or partner transfers without allowing negative balances.
  4. Auditability & Reconciliation: Provide daily reconciliation to detect and rectify discrepancies between source transactions and ledger credits.

Non-Functional Requirements

  1. Strict Idempotency: Payment gateways and upstream ledger services replay webhook events; duplicates must never yield double points.
  2. Strong Consistency for Balances: Avoid race conditions that could lead to double-spending of reward points.
  3. Rule Versioning Safety: Rule changes must not alter historical credits or create non-deterministic retro-calculations.

Scale & Traffic Estimates

  • Active Users: 5 million.
  • Daily Transactions: 10 million transactions/day (~120 TPS average, peaking at 1,500 TPS on promotional days).
  • Latency: Balance lookup < 50 ms (p95); ingestion processing within 5 seconds of event receipt.
  • Storage: Append-only ledger grows by ~15–20 million entries per day; multi-year retention required for compliance.

Key Design Deliverables

  • API Endpoints: Public/internal APIs for transaction webhook ingestion, balance retrieval, and redemption.
  • Data Model: Storage schema distinguishing rule definitions, ledger transactions, and user point balances.
  • System Architecture: High-level component diagram detailing ingestion pipelines, rule evaluation engine, and reconciliation workers.
  • Trade-Off Analysis: Justify relational vs. non-relational storage for the core ledger versus caching layers.

Hints

Hint 1

Model point adjustments as an immutable double-entry ledger where each entry references the source transaction ID and rule version ID.

Hint 2

Use a unique constraint on (source_transaction_id, transaction_event_type) to achieve idempotent ingestion at the database level.

Hint 3

Decouple read-heavy point balances using a materialized balance snapshot updated via database triggers or change data capture (CDC), backed by pessimistic or optimistic locking during point redemptions.

Follow-up questions

  • How would you handle retroactive adjustments, such as when an upstream transaction is refunded or disputed weeks later?
  • How can you safeguard against race conditions when a user attempts two simultaneous redemptions across different devices with an exact balance?
  • If business operators want to test complex new tier-based rules before rollout, how would you design a shadow-evaluation or backtesting framework?