How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Axon.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Axon during technical interviews.

Design a tamper-evident video chain-of-custody audit system

Quick Overview

Design a tamper-evident video chain-of-custody audit system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a tamper-evident video chain-of-custody audit system

System Design: Tamper-Evident Audit Logging for Video Evidence Chain of Custody

Design a scalable, tamper-evident audit logging system for video evidence that preserves an accurate chain of custody. The system must record all actions (upload, view, redact/delete sensitive data, transcribe), never lose an event, and support legal discovery.

Context and assumptions (add or adjust as needed):

Multi-tenant environment supporting thousands of agencies and millions of assets (videos, photos, transcripts).
Peak audit event rate: 10–50k events/sec; steady state 1–5B events/month.
Chain-of-custody must be legally defensible, with immutable, verifiable proof of event history.
Devices and users may be offline and later reconnect; the system must handle late/out-of-order arrivals without loss.

Specify the following:

Functional and non-functional requirements.
Architecture and storage choices (e.g., append-only log, replication, WORM/immutable storage).
Event schema, ordering, idempotency, and delivery guarantees (exactly-once vs at-least-once).
Integrity mechanisms (hash chaining/Merkle trees, digital signatures), encryption and key management, and access controls.
Scalability, partitioning, and backpressure handling.
APIs and query patterns for auditors and investigators.
Retention policies, legal hold, and compliance considerations.
Monitoring, audit-of-the-auditor, and disaster recovery.
Cost/latency trade-offs and capacity planning.
Testing, verification, and rollout plan.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Quick Overview

System Design: Tamper-Evident Audit Logging for Video Evidence Chain of Custody

Context and assumptions (add or adjust as needed):

Multi-tenant environment supporting thousands of agencies and millions of assets (videos, photos, transcripts).

Peak audit event rate: 10–50k events/sec; steady state 1–5B events/month.

Chain-of-custody must be legally defensible, with immutable, verifiable proof of event history.

Devices and users may be offline and later reconnect; the system must handle late/out-of-order arrivals without loss.

Specify the following:

Functional and non-functional requirements.

Architecture and storage choices (e.g., append-only log, replication, WORM/immutable storage).

Event schema, ordering, idempotency, and delivery guarantees (exactly-once vs at-least-once).

Integrity mechanisms (hash chaining/Merkle trees, digital signatures), encryption and key management, and access controls.

Scalability, partitioning, and backpressure handling.

APIs and query patterns for auditors and investigators.

Retention policies, legal hold, and compliance considerations.

Monitoring, audit-of-the-auditor, and disaster recovery.

Cost/latency trade-offs and capacity planning.

Testing, verification, and rollout plan.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.

If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.

Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.

State explicit assumptions before making sizing or architecture decisions.

Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.

API, data model, architecture, consistency, capacity, and operations.

Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.

A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?

How would you degrade gracefully during dependency failures?

What metrics and alerts would prove the design is healthy after launch?

Design a tamper-evident video chain-of-custody audit system

Quick Overview

Design a tamper-evident video chain-of-custody audit system

Design a tamper-evident video chain-of-custody audit system

System Design: Tamper-Evident Audit Logging for Video Evidence Chain of Custody

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP

Design a tamper-evident video chain-of-custody audit system

Quick Overview

Design a tamper-evident video chain-of-custody audit system

Design a tamper-evident video chain-of-custody audit system

System Design: Tamper-Evident Audit Logging for Video Evidence Chain of Custody

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP