# Design Correct Stateful Services for Irregular Financial Events Across several interview rounds, design an in-memory schemaless store, process loan principal and fee events that can arrive separately and out of order, schedule mortgage payments split across investors, and expose the workflow through an authenticated rate-limited API. ### Constraints & Assumptions - Columns have declared names and types, but an individual row may omit a column. - A payment allocates to fees before principal. - Principal and fee events for a period may arrive independently and must both be present before that period is finalized. - Remote dependencies can fail transiently, while some financial actions must not be duplicated. ### Clarifying Questions to Ask - What consistency and durability guarantees are required from the in-memory store? - What uniquely identifies a loan event and an accounting period? - Can a finalized period be corrected, and how is that correction audited? ### Part 1 — Schemaless store Choose data structures for typed sparse rows and implement selection, filtering, and projection with missing-column and type-mismatch semantics. #### What This Part Should Cover - Schema catalog and row representation - Predicate behavior for missing values - Projection aliases, validation, and complexity ### Part 2 — Loan event processor Define the state machine that waits for matching principal and fee inputs, handles out-of-order and duplicate events, applies fee-first allocation, and batches logs. #### What This Part Should Cover - Idempotency keys and period state - Deterministic ordering and correction rules - Atomic accounting updates and replay ### Part 3 — Payment scheduling Design scheduled payments that can be split among investors while preserving rounding, ownership changes, and reconciliation. #### What This Part Should Cover - A ledger rather than mutable balances alone - Exact decimal allocation and residual handling - Schedule versioning and investor settlement ### Part 4 — API boundary Specify CRUD endpoints, JWT authorization, rate limiting, thread-pool use, and bounded retries for remote data without duplicating side effects. #### What This Part Should Cover - Resource-level authorization - Per-principal or per-tenant quotas - Timeout, retry, circuit-breaker, and idempotency behavior ### What a Strong Answer Covers - Explicit invariants and failure states - Idempotent boundaries - Auditable recovery and reconciliation ```hint Use ledgers and state machines The hard requirement is not request throughput; it is deterministic recovery when inputs are late, duplicated, partially applied, or retried. ``` ### Follow-up Questions - How would you shard the sparse store? - How would you correct a payment after investor ownership changes?