Allowed R6 · Within policy
{
"slug": "crash-ingestion-pipeline",
"title": "Crash Ingestion Pipeline",
"difficulty": "hard",
"tags": [
"system-design",
"onsite",
"backend"
],
"is_free": true,
"locked": false,
"frequency": 0.6,
"last_reported_at": "2026-07-16T17:54:24.699509Z",
"url": "https://www.mokabla.com/en/c/instabug/crash-ingestion-pipeline",
"agent": {
"page": "https://www.mokabla.com/agent/en/c/instabug/crash-ingestion-pipeline",
"question": "https://www.mokabla.com/agent/_call/get_question?company=instabug&question=crash-ingestion-pipeline"
},
"company": {
"slug": "instabug",
"name_en": "Instabug"
},
"body_md": "## Problem\nDesign 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.\n\n## Examples\n**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.\n\n**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.\n\n## Constraints\n- p99 ingest ack under 200 ms at 20k requests/second peak\n- At-least-once transport from SDKs; exactly-once *counting*\n- Retain raw reports 90 days, aggregates for years\n\n## What they look for\nAn 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.",
"follow_ups_md": "- A customer's app sends malformed reports at 5k/s. How do you protect everyone else?\n- How do you compute 'users affected' rather than 'reports received'?\n- What is your strategy for schema evolution of the report payload?",
"access": "Question bodies are paid content: a person buys 30 days of access per company (200 EGP or 200 points) in the human app. Agents get titles, tags and difficulty; bodies only for free questions."
}