# Two Clocks > Fraud counts in seconds, finance counts by the hour. Build one platform that serves both. Canonical URL: Domain: Pipeline Design ยท Difficulty: medium ## Problem A payments company runs every card transaction through a fraud check that has to flag bad charges within seconds, while a vendor order API gets pulled once an hour to feed the finance team's reporting. Design both ingestion paths on one platform, each sized to the freshness its consumer actually needs. ## Worked solution and explanation ### What this is really asking This looks like a system-design question about a payments platform. It is really one judgment call asked twice: for each consumer, how stale can the data be before someone loses money. Fraud loses money in seconds. Finance loses nothing in an hour. The trap is reading 'one platform' as 'one pipeline' and shoving both consumers onto the same clock. Pick the wrong single clock and you lose either way. Stream everything and you pay 3 to 5x in compute and engineering for a freshness finance never reads. Batch everything on the hour and fraud waves through bad charges for up to sixty minutes before anyone looks. The senior move is to refuse the false choice: two consumers, two freshness budgets, two paths on one platform. ### The decision, made twice #### Step 1: Ask the money question per consumer For each consumer, ask: if this data were an hour old, does anyone lose money or make a bad call? Fraud, yes, instantly. Finance, no. That single question sorts each path into streaming or batch before you draw a single box. Answer it per consumer, never once for the whole platform. #### Step 2: Put fraud on the stream Card transactions already arrive as an event stream, and the decision has to land before authorization. That is the textbook case for streaming: a broker holds the events, a stream processor scores each one as it arrives, and the decision is written to a fast surface fraud reads in milliseconds. The source being event-based makes streaming the natural fit, not a stretch. #### Step 3: Put finance on a schedule The vendor exposes a REST API and finance reads on a daily and hourly rhythm. So pull the API once an hour on a scheduled job, page through the results, respect the rate limit, and load the hour's orders for reporting. Hourly is the freshness budget, so hourly is the clock. Spending streaming money here buys nothing. > **Trick to solving** > > Do not design 'the platform.' Design each consumer's freshness budget first, then let the budget pick batch or streaming. Two budgets means two paths, and 'one platform' just means they share infrastructure and a team, not a clock. > **Common pitfall** > > Collapsing both consumers onto one clock. Candidates either stream the vendor pull (paying 3 to 5x for an hour of freshness finance throws away) or batch the fraud check (a sixty-minute window where bad charges clear). Either one is a single sentence that sinks the design. **Fraud path** Source is already an event stream. Cost of staleness is immediate revenue loss. Freshness budget: seconds. Choice: streaming, with a processor scoring each event and writing to a fast read surface. **Finance path** Source is a pull-based REST API. Cost of an hour stale: nothing. Freshness budget: one hour. Choice: a scheduled batch pull that pages the API, handles the rate limit, and loads orders for reporting. > **Interviewers watch for** > > Whether you state the tradeoff out loud: streaming costs several times more in compute and engineering, so freshness has to earn it. A candidate who says 'batch is the default unless stale data costs money, and here it only costs money on the fraud side' has already passed the question. > **In production** > > When finance asks for 'real-time' during month-end close, the right answer is usually micro-batch, a five-minute pull, not a rewrite to true streaming. Push the clock from hourly to five minutes before you reach for Kafka and a stream processor on a path that was never event-driven to begin with. ## Common follow-up questions - Finance now wants five-minute freshness during month-end close. Do you make the finance path streaming? _(Tests whether the candidate reaches for micro-batch before true streaming when the source is not event-based.)_ - The hourly vendor pull sometimes runs longer than an hour. What breaks and how do you prevent two runs overlapping? _(Tests batch scheduling judgment: job-level locking so overlapping runs do not corrupt the load.)_ - The fraud stream processor crashes mid-stream. What do you lose and how do you recover? _(Tests awareness that streaming adds failure-recovery and ordering complexity that batch does not carry.)_ ## Related - [All practice problems](https://datadriven.io/problems) - [Mock interview mode](https://datadriven.io/interview/put-it-all-together-a-payments-company-ingests-card-transac-ffbf68e1) - [System Design Interview Questions](https://datadriven.io/data-engineering-system-design) - [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep) - [Daily Challenge](https://datadriven.io/daily) --- Source: DataDriven (https://datadriven.io). 100% free data engineering interview prep. Live code execution against Postgres 16, Python 3.11, and Spark sandboxes. No paywall, no premium tier, no signup gate.