Requirements, and What to Challenge
In one line: two of the numbers you are given in this problem are wrong until proven otherwise, and finding that out is the first five minutes.
The unit that changes everything
"Each camera produces 10mb/s" is the kind of line that appears in a real prompt, and it is ambiguous in a way that matters more than almost anything else you will decide.
Ten megabits per second is 1.25 MB/s. Ten megabytes per second is 80 Mbps. The gap between those two readings is a factor of eight in bandwidth, in storage and in bill.
Worth knowing which is plausible: a 1080p H.264 camera runs around 2–4 Mbps, and a 4K camera around 8 Mbps. Eighty megabits from a single fixed camera would be extraordinary — it is near-broadcast contribution quality, not surveillance. So the likely reading is megabits, and saying that out loud demonstrates you know the domain rather than just the arithmetic.
The retention number is a claim, not a constraint
"Store everything for at least 30 days" arrives sounding like a requirement. It is the single largest cost driver in the system, and it is frequently unexamined.
Under data protection regimes there is no fixed legal retention period — the governing principle is that personal data must not be kept longer than necessary for the stated purpose. Regulators treat anything past roughly 72 hours as needing a documented justification, and beyond 30 to 90 days as exceptional and purpose-specific. Common practice for general premises monitoring sits at 24–72 hours; 30 days is already the long end.
So thirty days is not obviously safe. It is the maximum you would defend, and defending it requires a purpose.
That gives you a genuinely strong move in the interview: ask what the retention is for. Three different answers give three different systems.
| Stated purpose | What it implies | Retention that actually serves it |
|---|---|---|
| Spot an incident and review it | Someone notices within days | 72 hours of everything |
| Support insurance or HR claims | Claims arrive weeks later | 30 days, but only of flagged events |
| Regulated audit obligation | A specific rule names a period | Whatever the rule says, immutably |
The middle row is where most real systems land, and it is much cheaper than what was asked for, because it separates everything for a short window from selected footage for a long one.
The questions that change the architecture
How many cameras, and where? A thousand cameras at one site is a LAN problem with abundant bandwidth. A thousand cameras across two hundred small sites is a wide-area problem where each site's uplink is the binding constraint, and it forces edge buffering into the design.
Continuous or event-triggered? Recording only when something moves cuts storage by an order of magnitude and introduces a correctness question — what happens in the gap — that continuous recording does not have.
How many watch live, and how live is live? This is the requirement most likely to be over-specified. A 1–2 second glass-to-glass budget is achievable but rules out plain segmented streaming, and the cost depends entirely on concurrent viewers, not on camera count.
What does "find footage" mean? Scrubbing a timeline for a known camera and time is a very different query from "find every clip with a person in the loading dock", and only the second one needs analytics metadata.
Who may see which camera? Surveillance footage is among the most sensitive data a company holds, and per-camera authorization is a functional requirement here rather than a hardening step.
Functional and non-functional, stated tightly
The functional surface is small:
- Ingest continuous streams from many cameras and store them durably.
- Play back an arbitrary time range for an arbitrary camera.
- View a camera live, on demand.
- Delete footage on schedule, and hold it when told to.
- Enforce who may see what, and log who saw it.
The non-functional requirements are where the design actually happens:
| Requirement | The design force it creates |
|---|---|
| Ingest never stops | Buffer at the edge; the pipeline must degrade, not drop |
| Storage dominates cost | Tiering and retention are first-class, not cleanup jobs |
| Reads are rare but urgent | Index for time-range lookup; do not cache the media |
| Live view is 1-2s when used | Protocol choice, and an on-demand path separate from archiving |
| Silent failure is the enemy | Continuity monitoring on every camera, not just liveness |
| Footage is highly sensitive | Per-camera authorization, short-lived URLs, full audit trail |
The scenario to commit to
Say it out loud and design against it:
"A thousand cameras across roughly fifty sites. 1080p H.264 at about 4 Mbps each, continuous recording. Thirty days of retention, and I will come back to whether all of it needs thirty days. Live view on demand with a 1–2 second budget, but only a handful of cameras watched at once — say fifty. Playback by camera and time range is the common query. I will treat every stream as personal data."
That paragraph fixes the bandwidth, the storage, the protocol choice, the read path and the security posture, and every later decision can be justified against it.
Key takeaway
Two numbers in this prompt deserve challenge before anything is designed. "10mb/s" is an eightfold ambiguity between megabits and megabytes, and surveillance cameras make megabits the plausible reading. Thirty-day retention is the biggest cost in the system and rarely justified — regulators treat long retention as exceptional, and asking what it is for usually splits the requirement into a short window of everything plus a long window of flagged events.
Next: the arithmetic, including one number that surprises almost everyone.