Incremental Opportunities for Public Projects — 2026-08-10
Scope: this window's Architecture/CaseStudies (Cloudflare, DoorDash) and Architecture/Fundamentals (consistent-hashing, load-balancing-algorithms) checked against Projects/public-projects.md. Prior passes (08-08, 08-09) covered idempotency keys, load balancing (partially), and Living-Harness/Discord SCP — this pass covers the two case studies not yet checked and the consistent-hashing fundamental against the two Redis/caching demo projects.
Cloudflare's connection-pool-exhaustion bottleneck is a direct diagnostic checklist for caching_projects and mongodb_caching
This window's Cloudflare case study traces a 10x throughput ceiling to two causes: serialized Kafka consumption that didn't need to be serial, and a client-side Postgres connection pool held open longer than necessary under load, which backpressures the entire fan-out. caching_projects ("Duplicate-entry checks and server-side read-through caching with Redis") and mongodb_caching ("MongoDB-backed response cache keyed by SHA-256 hash with TTL expiry") are both exactly the kind of small demo project where this failure mode is easy to reproduce and easy to miss — a read-through cache pattern that doesn't release its backing-store connection promptly under concurrent load will silently exhibit Cloudflare's exact symptom (throughput plateaus well below what the hardware should support) at a much smaller scale. Worth a documented load test on either project specifically checking connection-hold time under concurrent cache-miss bursts, framed explicitly against the Cloudflare case study's two questions: "is anything serialized here that doesn't need to be?" and "is the connection pool sized and released correctly under the actual concurrency this demo exercises?"
DoorDash's clusterless/bulk-refresh pattern reframes what mongodb_caching's TTL-based cache is actually optimized for
This window's DoorDash case study draws a sharp line between "bulk-refresh, read-heavy" workloads (where a stateless fleet fed by immutable snapshot files beats live cluster coordination) and "live-mutate" workloads (where clustering earns its cost). mongodb_caching's SHA-256-keyed, TTL-expiry cache is implicitly a bulk-refresh-shaped workload — entries are written once per unique request hash and read many times until TTL expiry, not continuously mutated. The DoorDash lesson ("question whether you need a clustered/coordinated backing store at all when the actual access pattern is bulk-refresh-then-read") is a concrete prompt for revisiting whether mongodb_caching's MongoDB backing store is solving a coordination problem the workload doesn't actually have, or whether it's already correctly sized for what is fundamentally a read-mostly, low-mutation-rate cache.
Not yet applicable
- Consistent hashing and load-balancing-algorithms map most directly onto
loadbalance_caddy,loadbalance_custom_network, andloadbalance_roundrobin_config, but those three demos are explicitly round-robin-focused per their own descriptions — a genuine "add a consistent-hashing variant" experiment would be new project work, not a documentation connection, so it's flagged here rather than written up as a finding.