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