# Exercise 1: Choosing a Storage Engine for a Metrics Platform

## Scenario

You're the infrastructure lead at `PulseMetrics`, building a time-series metrics ingestion platform. The write path: every monitored server pushes a new metric data point every 10 seconds, across 200,000 monitored servers — roughly 20,000 writes per second, sustained, 24/7, and this number only grows as customers onboard. Data points are essentially never updated once written (a metric reading from 3:04:10pm is immutable history). The read path is much lighter by comparison: dashboards query recent time ranges for a given server (`WHERE server_id = ? AND timestamp > ?`), and this traffic is bursty (spikes when someone opens a dashboard) but low-volume overall compared to the write firehose.

A candidate engineer on your team proposes using a traditional relational database with B-tree indexes on `(server_id, timestamp)`, arguing "B-trees are the industry standard, we shouldn't reach for something exotic."

## Deliverables

Produce all of the following, in this file, below this line:

1. **State which storage engine family you'd choose** (B-tree-backed relational store, vs an LSM-tree-backed store) **and justify it using the write:read ratio of this workload**, citing theory section 7 explicitly.
2. **Walk through what happens to a B-tree index under this write load**, referencing `02-b_tree/` section 5 (splits) and this topic's section 6 (write cost comparison table) — be specific about why 20,000 sustained writes/second is a meaningfully different regime than the read-heavy workloads B-trees excel at.
3. **Walk through what happens to an LSM-tree-backed store under this same load**, referencing sections 2-5 (memtable, SSTable flush, compaction) — explain concretely what the compaction background process would be doing continuously under this ingest rate, and why that's an acceptable trade here.
4. **Address the "immutable data" detail specifically**: does the fact that data points are never updated (only ever inserted) make LSM trees look even more favorable, or less? Reason from how updates/tombstones work in an LSM tree (section 4-5) — an append-only, no-update, no-delete workload is a special case worth calling out explicitly.

## Constraints

- Your justification must be grounded in the specific numbers given (20,000 writes/sec sustained vs bursty low-volume reads) — a generic "LSM trees are for big data" answer without connecting it to this workload's shape does not satisfy the deliverables.
- Acknowledge at least one real downside of your chosen engine for this workload, even if you still recommend it overall.