systems

design patterns that compose the concrete pieces documented elsewhere — queues, delivery semantics, cursors, batch/serving splits. the layer above any specific database, language, or protocol.

the boundary against its neighbours:

• storage/ and protocols/ — concrete systems (redis, sqlite, turso, turbopuffer, atproto, MCP)
• data-structures/ — implementation tradeoffs in reusable structures
• languages/ — language idioms (python, zig)
• operations/ — running and shipping what you built
• systems/ — the patterns that compose those things

if a note is mostly about what to do when something is already deployed and misbehaving, it belongs in operations/.

topics

• background-tasks — the celery→sidekiq→arq→docket lineage, why redis streams won over lists, perpetuals, scheduling future work (streams mechanics live in storage/redis/streams)
• at-least-once-forwarder — outbox, ack-after-durable-commit, and a cursor pinned to min(inflight); why ack-on-receipt plus shedding is silent loss
• serving-from-snapshots — build offline, verify against a manifest, adopt atomically; the overlay is authoritative, and batch cadence sets the freshness floor
• change-timestamps — "when we last wrote" and "when the content last changed" are different columns; pinning the wrong one turns a correctness gate into a measurement of write traffic
• watermark-semantics — one cursor, one meaning; the cost of a gate scales with the quantum of the thing it waits on
• prior-art-encodes-someone-elses-constraints — a mature schema's complexity is evidence of its constraints, not of its correctness for you; take the primitives, leave the envelope