rippling·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

May 2026

Summary

Rippling system design round for a software engineering role. The question was about extending an expense-approval rule engine to handle group-level rules, no coding needed, just talking through the design. Pretty conceptually dense for a single question.

Questions Asked (1)

You have an expense-approval rule engine where each rule applies to a single expense. How would you extend it to support group rules, ones that operate over a set of expenses (e.g. total monthly travel spend across a team, or max 5 expenses per employee per day)? Walk through group key design, stateful aggregation, evaluation timing, and how group rules interact with individual rule decisions.

System DesignTechnical Trade-offsData Modeling

Author's notes

This one took me a minute to even figure out where to start.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a design that separates group rule definitions from their stateful evaluation, using a group key to aggregate expenses. Walk through the lifecycle: how group keys are formed, how state is maintained, when evaluation triggers, and how group decisions combine with individual rule outcomes.

Pro tip: Emphasize idempotency and eventual consistency: group rules often require asynchronous processing, so design for exactly-once semantics and handle late-arriving expenses gracefully.

1. Clarify Requirements and Constraints

Ask about scale, latency tolerance, consistency needs, and whether group rules can override individual decisions. This shapes the entire design.

2. Design Group Keys and Rule Definitions

Define how to derive a group key (e.g., team+month for travel spend) and how group rules are configured, including aggregation type (sum, count, max) and thresholds.

3. Choose Stateful Aggregation Strategy

Decide where and how to maintain group state: in-memory, database, or stream processing. Consider incremental updates vs. recomputation and handling of late data.

4. Determine Evaluation Timing and Triggers

Specify when group rules are evaluated: on each expense submission, periodically, or at period close. Discuss synchronous vs. asynchronous evaluation and its impact on user experience.

5. Integrate with Individual Rule Decisions

Define precedence and conflict resolution: can a group rule block an expense that passed individual rules? How to combine outcomes (e.g., AND, OR, override) and communicate decisions.

Key Points to Mention

Group key design: composite keys (e.g., employee_id + date, team_id + month) and how to handle changes (e.g., employee transfers).
Stateful aggregation: using a database with atomic increments, or a stream processor like Kafka Streams/Flink for real-time aggregation.
Evaluation timing: synchronous (blocking) vs. asynchronous (eventual) evaluation, and trade-offs in latency and consistency.
Idempotency and exactly-once processing to avoid double-counting expenses.
Interaction with individual rules: precedence rules, conflict resolution, and whether group rules can override individual approvals.
Scalability and partitioning: sharding by group key to distribute load and avoid hot partitions.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.