Katkat
Back

Design a chargeback ingestion and export system

NubankSoftware Engineer · Onsite
EasySoftware EngineerOnsiteSystem Design

Last updated

This question assesses the ability to design a distributed system that reliably ingests high-volume transaction records and prepares them for periodic downstream delivery while ensuring data consistency and auditability.

Scenario

You are tasked with building a chargeback processing system for a fintech platform. The system must ingest chargeback requests from external payment networks (e.g., Visa, Mastercard) via a webhook and generate a daily batch file to be uploaded to an internal accounting system via SFTP.

Requirements

  • Ingestion: Accept high-volume, asynchronous incoming webhook events containing transaction ID, chargeback amount, currency, merchant ID, and timestamp.
  • Reliability: Ensure zero data loss for incoming events. The system must handle network timeouts and downstream failures gracefully.
  • Idempotency: Incoming webhooks might be retried by the provider; the system must not create duplicate entries for the same chargeback event.
  • Export: Once every 24 hours, generate a CSV file containing all unprocessed chargeback records from the previous day.
  • Data Integrity: Track the state of each chargeback (e.g., RECEIVED, QUEUED, EXPORTED).

Scale Assumptions

  • Ingest roughly 50,000 chargeback events per day.
  • The system must be able to handle sudden traffic spikes (e.g., 5x normal volume during peak shopping seasons).
  • PII data must be encrypted at rest.

Requirements for your Design

  1. Propose a high-level architecture diagram or component list.
  2. Define the data model for the database schema.
  3. Discuss the retry strategy for failed webhooks and failed SFTP uploads.
  4. Explain how you would handle data consistency during the file generation process.

Hints

Hint 1

Consider using an asynchronous message queue between the ingestion layer and the database to decouple traffic spikes from processing logic.

Hint 2

Use a state machine within the database to track the lifecycle of each chargeback record to prevent accidental double-processing.

Hint 3

Think about using a temporary 'staged' or 'locked' status when picking up records for file generation to ensure atomicity across your read and write operations.

Follow-up questions

  • How would you handle a scenario where the downstream SFTP service is down for an extended period?
  • What monitoring and alerting mechanisms would you implement to ensure we are meeting our daily export SLAs?
  • How would you ensure compliance regarding PII masking when logs or debug traces are generated by this system?