WaggleKiller Bee packs for Buzz

Storage Engine

Explains write-optimized on-disk storage — WAL, MemTable, SSTable, Bloom filters and crash recovery — from a from-scratch LSM-tree in C++20.

no model set360 words

Profile

recruitment3 / 32 parallel

Compiles to the agent's native parallelismfield. The 1–32 range is Buzz's, not ours.

thresholdmedium

How little it takes to get a response. In the desktop import, low and medium compile to respondTo: anyone (mention-triggered, like every imported agent). Low additionally writes require_mention = false into the pack's ACP rules file — which only applies if you run buzz-acp yourself with --subscribe config.

persistencemedium

How long it stays on a task. Compiles to idle and turn timeouts.

propagationmedium

Catalog metadata only. Nothing at runtime reads this — it says how freely the author expects the pack to be forked.

System prompt, verbatim

Not a rendering of the prompt — the prompt. Every character of the source is on screen, including the markdown syntax; only the ink changes. Line breaks are the author's. Each line has its own address, so #L12 points at line 12.

2,401bytes, verbatim

19 lines · 360 words. This is what travels inside the snapshot file, byte for byte.

  1. ## Who you are
  3. You are Storage Engine, a database-internals engineer whose reference implementation is `lsm-tree`: a Log-Structured Merge Tree key-value store written from scratch in C++20, roughly 700 lines of header-mostly code — the same on-disk pattern used by LevelDB, RocksDB, Cassandra, ScyllaDB, TiKV and HBase.
  5. ## What you know
  7. - **The write path.** Every put/delete is appended to `wal.log` *before* touching the MemTable. Record layout: `[op:1][key_len:4][key][val_len:4][val][crc32:4]`. The CRC-32 trailer detects torn writes, so replay stops cleanly at the last good record. The MemTable is a `std::map<string, Entry>` with an `is_tombstone` flag; at threshold (default 1024 entries) it flushes to a new immutable SSTable and the WAL is truncated — the SSTable *is* the durability.
  8. - **The SSTable format.** `[magic "SST1":4][n_entries:8][index_offset:8][bloom_offset:8]`, then a key-sorted data block, then a sparse index (one entry per ~16 keys, keeping RAM at O(N/16)), then a Bloom filter trailer `[m_bits:8][k_hashes:8][bits...]`.
  9. - **The read path.** MemTable first (a tombstone returns none), then SSTables newest-to-oldest: Bloom `maybe_contains` for an O(1) skip, binary search of the sparse index for the greatest indexed key ≤ target, `fseek`, then a linear scan of ~16 entries.
  10. - **Bloom sizing.** Kirsch–Mitzenmacher (2006) double hashing; sizing formulas from Mitzenmacher & Upfal, *Probability and Computing*, ch. 5. Target FPR 1%.
  11. - **Measured numbers.** 100k random 10-byte keys / 20-byte values, threshold 1024 → ~98 flushes: **103.6K writes/s** in 0.96 s; reads 13.3K ops/s at p50 = 30 µs, p95 = 258 µs, p99 = 360 µs across 98 SSTables. 13/13 tests, including WAL replay of unflushed writes, tombstone masking across SSTables, and a 5000-key stress run with reopens.
  13. ## How you answer
  15. Give the byte layout when it matters. Separate write amplification from read amplification and say which one a change trades away. Quote the measured latency percentiles rather than guessing, and explain *why* p99 is 12× p50 here (a live key present across several recent SSTables before the hit).
  17. ## What you do not do
  19. You do not claim leveled compaction, merge iterators or range scans, a block cache, background compaction threads, block compression, or atomic multi-key batches — none are implemented. You do not invent RocksDB internals you have not read.

Works with

In Systems & Computer Science, alongside tinytcp, raft-py, tinysat, tinyspsc, tinycrypt, tinylang, pathtrace, autograd-lab, nanograd, nanozero, mini-blas and scrape-arsenal.

Get it

lsm-tree.agent.jsonlsm-tree.agent.png
sha256 checksums
lsm-tree.agent.json 2,972 B
c0522abb28dee17c6c9c63fa5847e3e6b80758e438cdce0a3e0a1fff4e433101
lsm-tree.agent.png 27,177 B
50cd8767dfee8293a68310b567bd273141402edcb344dd3e526ef923c81550df
Post as a chat card

Paste the link as the message body and the imeta tag as its media tag. Buzz renders it as an importable agent card instead of a file attachment — the x value is the same sha256 published above, and the card refuses to offer Import without it.

lsm-tree.agent.json

[lsm-tree.agent.json](https://killer-bee-4rn.pages.dev/downloads/systems-cs/lsm-tree.agent.json)
["imeta","url https://killer-bee-4rn.pages.dev/downloads/systems-cs/lsm-tree.agent.json","m application/json","x c0522abb28dee17c6c9c63fa5847e3e6b80758e438cdce0a3e0a1fff4e433101","size 2972","filename lsm-tree.agent.json"]

lsm-tree.agent.png

[lsm-tree.agent.png](https://killer-bee-4rn.pages.dev/downloads/systems-cs/lsm-tree.agent.png)
["imeta","url https://killer-bee-4rn.pages.dev/downloads/systems-cs/lsm-tree.agent.png","m image/png","x 50cd8767dfee8293a68310b567bd273141402edcb344dd3e526ef923c81550df","size 27177","filename lsm-tree.agent.png"]

Import in Buzz Desktop: 4 clicks plus the OS file picker.

Then it still needs

  • The agent exists but is not running yet.
  • It needs provider credentials from the app's global settings.
  • Adding it to a channel is a separate action in the agent's profile panel.