CRED System Design Interview: Bill Payments and Rewards at Scale

The gated member. eligibility_state tracks whether the bureau check is pending, passed, or failed. The score itself is used at the gate and not necessarily stored in detail. Admission depends on clearing the threshold.

A member's linked credit card, with the current bill and due date that drive both the payment and the monthly load pattern. Sensitive data is tokenized or masked.

The central order record and the source of truth for any action in the system. type selects which state machine applies. state is the current position in that machine. Owned by the order management system.

The full, immutable history of every state change on an order, with the event that caused it. This is what powers accurate status tracking, support, and audit, and lets the current state always be reconstructed.

The money legs of an order: charging the member and paying the issuer. Idempotent so a retry never double-moves money. Provider references tie back to the bank or gateway. Strong consistency required.

Rewards granted for qualifying actions, driven by order events. Surfaced to the member in real time through the push platform.

A centralized order platform versus per-product order systems

Letting each product own its order handling is faster to build at first and keeps teams independent, which is why CRED started that way. But once many products each maintain their own order lifecycle, the logic is duplicated and drifts out of sync, and cross-product features get hard. CRED consolidated into one centralized order management system as the source of truth. The cost is building and governing a shared platform that many teams depend on, accepted because it removes duplication and gives one consistent view of every order.

Explicit state machines versus status flags

Tracking an order with a few status fields updated wherever convenient is simple, but for a money movement that spans several services it leads to ambiguous and inconsistent states. Modeling each order type as an explicit state machine with recorded transitions makes the lifecycle correct, prevents illegal jumps, and keeps a full audit trail. The cost is the upfront design of the state machines and the discipline to drive all changes through them, accepted because payment correctness and auditability depend on it.

Event-driven transitions versus synchronous orchestration

The order service could call each fulfillment step synchronously and wait, which is easier to trace, but it couples the order core to every downstream service and blocks on the slowest. Driving transitions from events that fulfillment services emit keeps the order core decoupled and resilient to slow or temporarily failing steps. The cost is the harder reasoning that comes with asynchronous, eventually-arriving events, which is managed by the recorded state history and idempotent handling.

Real-time push versus polling

Polling is trivial to implement, but it adds latency, wastes requests when nothing changed, and can cause retry storms at scale. A persistent push connection, as in CRED's propeller, delivers updates instantly and cuts wasted traffic. The cost is maintaining many long-lived connections and the fan-out infrastructure, accepted because a premium product needs the responsiveness and because the event-driven core already produces the updates to push.

Asynchronous eligibility check versus blocking signup on the bureau

Blocking the whole signup until the external credit-bureau call returns is simplest, but a slow or failing bureau would freeze onboarding for everyone. Treating the eligibility check as an asynchronous, retryable step with an explicit member eligibility state keeps signup responsive and degrades gracefully when the bureau is slow. The cost is handling the pending state in the app and the retries, accepted because the check depends on a third party that cannot be allowed to block the funnel.