Design camera-footage upload with custody chain
Company: Axon
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Technical Screen
## System design prompt
You’re building a backend service for uploading **recorded body-camera / dashcam footage** from client devices (often on unreliable networks). Uploaded videos may later be used as **legal evidence**, so the system must support large files, security scanning, and a **tamper-evident chain of custody**.
### Core requirements
1. **Large blob uploads**
- Video files can be multiple GBs.
- Upload must be **resumable** and tolerate flaky connectivity.
- Clients may upload in **chunks**.
- Assume you **cannot fully trust the cloud provider’s built-in multipart “finalization”** (i.e., you must be able to prove server-side what bytes were received and assembled).
2. **Malicious content detection**
- Newly uploaded blobs must be treated as untrusted.
- Run security checks (e.g., malware scan, file-type validation) before making content available to users or downstream systems.
3. **Chain of custody**
- You must produce an auditable, tamper-evident history of all actions on a piece of footage (upload, scan results, moves, access/download/export, retention/legal hold changes, deletion).
- The system should help prove that footage was not altered.
### What to cover
- APIs and data model (upload session, chunk tracking, metadata)
- Storage layout (quarantine vs public/evidence)
- Background processing pipeline (assembly, scanning, promotion)
- Integrity verification approach (checksums/hashes)
- Chain-of-custody design (immutable audit log)
- Access control and security considerations
- Key tradeoffs and failure/edge cases
Overview: This question evaluates a candidate's ability to design resilient, secure large-file ingestion systems with integrity verification, resumable chunked uploads, malware and file-type scanning, and an auditable tamper-evident chain of custody, commonly asked to assess architectural thinking about reliability, security, and compliance for evidentiary data. It is in the System Design domain (storage, APIs, background processing, and audit logging) and tests practical application of architectural trade-offs, failure-mode reasoning, and operational concerns rather than only theoretical concepts.
Read the full Axon Software Engineer interview experience this question came from
Community answers
Answer by Mohit2289
1. 🛡️ api-gateway-service
·
What it is for: The reactive, non-blocking single entry point for all incoming traffic
(external devices and internal clients). It acts as the gatekeeper for
authentication, rate limiting, and distributed tracing.
·
Why we designed it this way:
o
Netty Non-Blocking Engine: Body cameras upload huge chunks of data.
Traditional servlet containers (like Tomcat) dedicate one thread per request,
which would quickly exhaust the gateway's memory threads during a shift change.
Netty uses a minimal event loop architecture to handle thousands of concurrent
active connections.
o
Perimeter Security Offloading: By handling Mutual TLS (mTLS) certificate
validation and Token Bucket rate limiting via a fast Redis cache at the
gateway, we ensure that unauthorized or malicious spam traffic is blocked
immediately before wasting any downstream application compute or storage
resources.
2. ⚙️ upload-coordinator-service
·
What it is for: A lightweight orchestration microservice that handles the initial
handshake, tracks upload session lifecycles, and maintains the database state
of expected versus received file chunks.
·
Why we designed it this way:
o
Isolation of State Management: Orchestrating an upload session involves constant
database reads and updates. Separating this from the heavy byte-streaming
service prevents database connection pool starvation.
o
Failover Status Inquiries: When a camera drops connection mid-upload, it
queries this service (GET
/v1/uploads/ses