A regulated platform must retain audit events for seven years. It generates about 400 million events a day at roughly 1.2 KB each. Which estimate and which design consequence are right?

The assumptions, stated

400 million events a day, 1.2 KB each as serialised JSON, seven years of retention, and audit events that are highly repetitive - the same field names, the same actor and resource identifiers, the same action verbs - which is what makes the compression assumption reasonable.

The arithmetic, step by step

1. Raw per day: 400,000,000 × 1.2 KB = 480 GB a day, call it 0.5 TB.
2. Raw over seven years: 0.48 TB × 365 × 7 ≈ 1.23 PB.
3. Compressed: audit records in a columnar format with dictionary encoding commonly reach 8:1 to 15:1 on this kind of data. At 10:1 the stored volume is about 120 TB.
4. Storage cost: at archive-tier object-storage list prices in 2025 of roughly $1 to \(4 per terabyte-month, 120 TB is about **\)150 to $500 a month**, or $12k to $40k over the seven years. For a regulated platform that is a rounding error.
5. The costs that are not storage: retrieval fees on archive tiers (often charged per gigabyte retrieved, and an audit investigation may retrieve a lot), the compute to scan an uncompressed equivalent of over a petabyte if a query is written carelessly, and the index that makes "who touched account X in March 2021" answerable at all.

The number, with its range

About 120 TB stored, in a range of 80 TB to 155 TB depending on the compression achieved, from 1.23 PB raw. The monthly storage bill is in the hundreds of dollars; the queryability is the expensive part.

Which assumption dominates the error

The compression ratio, which moves the answer by a factor of two, followed by the event-size estimate. Neither changes the design conclusion, which is why this estimate is worth doing roughly and quickly: no plausible input makes storage the problem.

Why the other options fail

• 12 TB compresses by 100:1, which no realistic encoding achieves on this data.
• 1.2 PB compressed confuses raw with stored and leads to the wrong conclusion - a storage negotiation instead of an access design.
• 500 TB with egress dominating assumes the data leaves the cloud. Audit data is queried in place; if your design egresses petabytes of audit data, that is the finding.

When this is the wrong estimate to spend time on

When the retention period is short enough that one hot store covers it - under about 18 months at this volume - the tiering design is unnecessary complexity and a single partitioned table is both cheaper and easier to query. The estimate is also the wrong focus when the obligation is integrity rather than volume: if the requirement is write-once storage with tamper evidence, the design question is the storage mode and the key custody, and the terabytes are incidental.

What the number rules in or out

It rules out a single hot store for seven years, and rules out archive-only. The design that follows is tiered by access pattern, not by age alone:

• Hot and indexed for 30 to 90 days, covering incident response, which is nearly all real access.
• Warm columnar on standard object storage for 1 to 2 years, partitioned by day and by tenant so that a targeted query reads gigabytes rather than terabytes.
• Archive tier beyond that, with a documented restore procedure and a tested restore, because an archive you have never read is not evidence.
• A small separate index of actor, resource and day for the whole seven years - a few hundred gigabytes - so a question can be answered without scanning the archive. This is the single highest value component and the one most often missing.