Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Design API Idempotency Data Pipeline

HardPipelines00:00
Practice interviewer
In session
5 left
00:00

Your question is Design API Idempotency Data Pipeline. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

LedgerFlow, a B2B payments platform, exposes a core API for payment creation, refunds, and ledger mutations. Today, retries from clients, load balancers, and downstream workers can produce duplicate side effects, and the current batch reconciliation process detects issues hours later. You need to design an idempotency framework as a data pipeline problem: capture requests, deduplicate safely across synchronous API and asynchronous processing, and provide replay, auditability, and monitoring.

Scale Requirements

  • Traffic: 35K API requests/second peak, 8K average
  • Payload size: 1-8 KB JSON per request
  • Idempotency window: 72 hours for external clients, 30 days audit retention in hot storage, 1 year in cold storage
  • Latency target: P99 API overhead from idempotency checks < 25 ms
  • Durability: No duplicate side effects for committed operations under retries, worker restarts, or network timeouts
  • Storage: ~2.5B idempotency records/month

Requirements

  1. Design a framework that guarantees the same idempotency key + request fingerprint returns the same result without re-executing side effects.
  2. Support both online request handling and async pipeline stages (Kafka consumers, Airflow backfills, replay jobs).
  3. Define the storage model for idempotency keys, request hashes, response snapshots, processing state, TTL, and audit metadata.
  4. Handle race conditions from concurrent duplicate requests across multiple API pods and regions.
  5. Prevent false reuse when the same key is sent with a different payload.
  6. Support reprocessing/backfills while preserving idempotent writes into downstream warehouse tables.
  7. Include monitoring, alerting, dead-letter handling, and operational recovery procedures.

Constraints

  • AWS-first stack; existing services use EKS, PostgreSQL, Kafka, Airflow, and S3
  • Budget increase capped at $40K/month
  • PCI and SOX audit requirements; immutable audit trail required
  • Cross-region active/passive failover; RPO < 5 minutes, RTO < 30 minutes