Katkat
Back

Design a flexible expense reimbursement system

RipplingSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This question evaluates system design and architecture skills for building a policy-driven, explainable expense reimbursement platform, specifically testing competencies in rule engines and DSL/config design, versioning and immutable evaluations, group-level aggregation and conflict resolution, data modeling and partitioning for scale, API and workflow design, observability/auditing, and access control. As a System Design interview prompt it is commonly asked because it forces candidates to articulate trade-offs between extensibility, explainability, consistency, and performance; the assessment targets practical application of architectural principles with strong conceptual reasoning.

Design an expense reimbursement system that supports pluggable, evolvable approval rules and group-level constraints. Requirements:

  1. Allow administrators to add/modify rules (e.g., per-category caps, receipt required, merchant whitelist, per-diem by city) without redeploying code; ensure versioning, effective dates, and explainable outcomes.
  2. Support grouping expenses by a condition (e.g., same business trip/project, report, or cost center) and enforcing group policies (e.g., total per trip ≤ $2, 500).
  3. Resolve conflicts when an item passes item-level rules but the enclosing group fails (e.g., a $20 meal is valid individually, but the trip totals $3,000 and exceeds a $2,500 cap); return a clear decision that distinguishes item-level vs group-level reasons and surfaces which items are only failing due to group constraints.
  4. Propose a data model (users, expenses, categories, receipts, trips/projects, reports, groups, rules, rule versions, evaluations, audit logs) and discuss indexing/partitioning for scale.
  5. Describe the rule engine design (rule DSL/config schema, execution graph, ordering/precedence, short-circuiting, caching of aggregates, idempotency, and re-evaluation on policy updates).
  6. Define APIs and workflows (submit expense, create/update group, evaluate, re-evaluate, manual override, appeal) and specify latency/consistency expectations.
  7. Address edge cases (multi-currency and FX timing, split expenses across categories, duplicates, offline receipts, partial approvals, concurrency when the same expense belongs to or moves between groups).
  8. Cover observability, auditing, and access controls for financial/PII data, plus rollout strategies (dry-run/A-B) for new policies. Provide a high-level architecture and explain your trade-offs.