Crash Ingestion Pipeline

Problem

Design the backend that receives crash reports from mobile SDKs embedded in thousands of apps. A report is a few KB of JSON (stack trace, device, app version, breadcrumbs) plus optional attachments up to 5 MB. Traffic is spiky: a bad release of a popular app can produce 200,000 reports in ten minutes from the same crash. The product needs: a "new crash" alert within a minute, grouping of reports into issues by stack-trace fingerprint, symbolication of native/obfuscated frames, and a dashboard that shows counts per issue per version with sub-second queries. Reports must never be lost, and the same report retried by the SDK must not be counted twice.

Examples

Example 1 (spike), 200k identical crashes in 10 minutes. Show how the ingestion tier stays up (accept and acknowledge fast, process later), how the grouping step avoids 200k writes to the same issue row (aggregate in the stream before touching the database), and how alerting fires once rather than 200k times.

Example 2 (late symbolication), Reports arrive before the developer uploads the dSYM for that build. Fingerprinting on raw addresses would create a wrong group; show how you fingerprint provisionally, store the raw frames, and re-group when the mapping file lands.

Constraints

• p99 ingest ack under 200 ms at 20k requests/second peak
• At-least-once transport from SDKs; exactly-once counting
• Retain raw reports 90 days, aggregates for years

What they look for

An edge tier that validates and writes to a durable log immediately, idempotency keyed on a report id generated on device, stream processing for fingerprinting and pre-aggregation, an object store for attachments, a columnar or time-series store for the dashboard, and explicit handling of the re-symbolication back-pressure problem.