## Design a Configurable Reward Points Service Design a reward-points service that reads transactions, calculates and stores rewards, and supports business rules that change over time without a code deployment. The design should be able to evolve to integrations such as webhooks and a separate points-spending service. Address exactly-once user-visible effects and compare relational with nonrelational storage instead of choosing by habit. ### Part 1 — Define the Ledger and Service Contract Specify transaction ingestion, reward calculation, balance or ledger reads, and the records needed to explain a points decision. #### What This Part Should Cover - Stable transaction, member, reward-entry, and rule-version identities. - Append-only reward effects versus a mutable balance projection. - Pending, awarded, reversed, and failed lifecycle semantics where required. - APIs or events for ingesting transactions and reading calculation status. ```hint Keep effects explainable A balance alone cannot show which transaction and rule version created each points change. ``` ### Part 2 — Make Rules Configurable and Safe to Change Design the rule representation, validation, versioning, activation, and rollback path so a new rule does not require deploying application code. #### What This Part Should Cover - A bounded rule language or typed configuration rather than arbitrary executable code. - Effective-time and rule-version semantics for late or replayed transactions. - Static validation, simulation against historical fixtures, staged activation, and rollback. - Recalculation policy when a rule is corrected after rewards were issued. ```hint Bind every calculation to a version Without the exact active rule version, a later replay cannot distinguish a legitimate historical result from drift. ``` ### Part 3 — Deliver Exactly-Once Effects over Retryable Work Trace a transaction through ingestion, calculation, persistence, and event publication under duplicate delivery and worker failure. #### What This Part Should Cover - Idempotency keys and a database uniqueness boundary. - Atomic reward-ledger write plus outbox publication. - Inbox or consumer deduplication for downstream services and webhooks. - Recovery from a crash before commit, after commit, or after an external timeout. ```hint Define exactly what is unique Exactly-once transport is not required when every retry converges on one durable reward effect with one stable identity. ``` ### Part 4 — Add Spending, Webhooks, and Storage Evolution Explain how a points-spending service and webhook consumers interact with the reward ledger. Compare SQL and NoSQL choices using the access and consistency requirements. #### What This Part Should Cover - Atomic or reservation-based prevention of overspending. - Ordered, signed, retryable webhook delivery with observable status. - Relational constraints and transactions versus partition-scaled document or key-value access. - Reconciliation, audit history, metrics, and a migration path as requirements grow. ```hint Choose storage from invariants If awarding and spending must preserve a balance constraint, explain where that invariant is enforced before optimizing the read model. ``` ### What a Strong Answer Covers - Treats rewards as an auditable ledger derived from versioned rules. - Changes configuration through validation and staged activation rather than arbitrary code execution. - Achieves exactly-once effects with idempotent state transitions, uniqueness, and an outbox. - Integrates spending and webhooks without weakening balance or replay guarantees. ### Follow-up Questions 1. Which rule version applies when an old transaction arrives after a new rule activates? 2. How would you correct an erroneous rule without erasing the original ledger evidence? 3. What happens when a webhook receiver accepts an event but its response times out? 4. Under what measured workload or access pattern would you move part of the design away from SQL?