| new file mode 100644 |
| index 0000000..6c42214 |
| --- /dev/null |
| +++ b/docs/comparison-carbon.md |
| @@ -0,0 +1,171 @@ |
| +# 🤖 How the carbon compares |
| + |
| +The third leg of the comparison series — the siblings are |
| +[comparison.md](comparison.md) (the product) and |
| +[comparison-infrastructure.md](comparison-infrastructure.md) (the |
| +architecture's prior art). This one estimates what the |
| +[#550 architecture](https://github.com/elevenmessenger/messenger/issues/550) |
| +— one hibernating single-binary instance per space, state parked in S3 as |
| +ciphertext — costs the planet at scale, against the conventional |
| +alternative: a multi-tenant Rails monolith on a Kubernetes fleet with a big |
| +always-on database tier. |
| + |
| +The short version: at a million spaces (~10M members), the Eleven model |
| +works out to roughly **10–50× more carbon-efficient**, central estimate |
| +**~30×** — on the order of **2 g CO₂e per member per year** against ~75 g |
| +for the conventional stack. The headline mechanism isn't any one trick: |
| +it's that a compiled binary, in-process SQLite, scale-to-zero hibernation, |
| +no control plane, and E2EE-foreclosed server work *multiply*. |
| + |
| +Everything here is a Fermi estimate with ±2–3× error bars, and the |
| +absolute numbers are softer than the ratio — most of the uncertainties |
| +(grid intensity, PUE, utilization assumptions) hit both sides and cancel. |
| +The inputs are real, though: the Eleven side starts from live measurements |
| +of the production fleet. |
| + |
| +## The measured starting point (production box, 2026-07-11) |
| + |
| +The entire Eleven production — 15 running instances (every real space plus |
| +canaries), the router, all four sibling services (home, push relay, connect |
| +broker, cloud provisioner), and five AI bot sidecars — measured live: |
| + |
| +| what | measured | |
| +|---|---| |
| +| A warm instance (whole app: server, DB engine, frontend) | **20–28 MB RSS**, avg ~23 MB | |
| +| Router + all four sibling services | ~110 MB combined | |
| +| A Go bot sidecar | ~18 MB | |
| +| **The whole fleet** | **~550 MB RAM, load average 0.21 on 2 ARM vCPUs** | |
| +| Hibernated instances (7 of 22 on disk at measurement time) | **0 MB, 0 CPU** | |
| +| A space's entire E2EE history (SQLite ciphertext) | 1–16 MB | |
| + |
| +That last table row pair is the whole story in miniature: the marginal cost |
| +of a *sleeping* space is a few megabytes of object storage, and the |
| +marginal cost of an *awake* one is ~23 MB of RAM and almost no CPU. Today's |
| +entire production draws a single-digit-watt slice of one shared server — |
| +less than a nightlight. |
| + |
| +## The scenario: 1M spaces, ~10M members |
| + |
| +The anchor scale is the #550 plan's own 1M-space column. Coefficients are |
| +from the [Cloud Carbon Footprint](https://www.cloudcarbonfootprint.org/docs/methodology/) |
| +methodology (~2 Wh per vCPU-hour at typical utilization, ~0.39 W per GB of |
| +RAM, ~1 Wh/TB-hour for replicated object storage), AWS's published fleet |
| +PUE of ~1.15, and a location-based grid intensity of 350 g COâ‚‚e/kWh |
| +(between the IEA global average of ~480 and typical European cloud |
| +regions; sensitivity discussed below). |
| + |
| +### The Eleven fleet |
| + |
| +| assumption | value | basis | |
| +|---|---|---| |
| +| Spaces awake at any moment | ~10% (range 5–20%) | group chats are bursty; hibernation on idle | |
| +| Warm set | 100k × ~25 MB ≈ 2.5 TB active RAM; provision ~6 TB | measured RSS | |
| +| Messages | 10M members × 100/day ≈ 12k msg/s average | generous | |
| +| CPU | a few hundred vCPUs busy; ~1,000 provisioned | ~1–5 ms CPU per message incl. WS fan-out; RAM, not CPU, is the binding constraint (the live box serves everything at load 0.2) | |
| +| Space state | ~15 TB of SQLite ciphertext in S3 | measured 1–16 MB per space | |
| +| Attachments | ~100 TB on zero-egress object storage | the plan's figure | |
| + |
| +Power: CPU 1,000 vCPU × 2 Wh/h ≈ 2.0 kW; RAM 6,000 GB × 0.39 W ≈ 2.4 kW; |
| +object storage (both buckets, 3× replicated) ≈ 0.3 kW; NLB, activator, |
| +sibling services, network ≈ +15%. Times PUE 1.15: |
| + |
| +**≈ 6 kW continuous** (range 3–12 kW) → ~53 MWh/yr → **~18 t CO₂e/yr |
| +operational**. Embodied carbon: this is only ~8–10 physical servers' |
| +worth of hardware plus a slice of the storage fleet — ~4 t/yr amortized |
| +over a 5-year life. **Total ≈ 22 t CO₂e/yr ≈ 2 g per member per year**, |
| +or about **0.5 joules of server energy per message**. |
| + |
| +### The conventional comparator |
| + |
| +The best public calibration point for a Rails fleet is |
| +[37signals' cloud exit](https://world.hey.com/dhh/the-hardware-we-need-for-our-cloud-exit-has-arrived-99d66966): |
| +~4,000 vCPUs and ~7.7 TB of RAM of purchased hardware to run Basecamp + |
| +HEY — order 1–2M users — and that's a famously *lean* shop (Kamal, no |
| +Kubernetes, tight packing). Scaled to 10M users: ~20,000 vCPUs, ~40 TB |
| +RAM, roughly **75–100 kW**. |
| + |
| +A *typical* multi-tenant Kubernetes deployment is materially heavier than |
| +that baseline. Industry container surveys (Datadog's container reports) |
| +put actually-used CPU at ~20–30% of requested; on top sit the control |
| +plane, service-mesh sidecars, the observability fleet (metrics, logging, |
| +tracing — commonly 10–20% of nodes), staging environments, and an |
| +always-on HA Postgres + Redis + search tier provisioned for peak with no |
| +scale-to-zero anywhere in the stack. That lands at **~150–300 kW** — |
| +call it 200 kW central: |
| + |
| +**≈ 200 kW** → ~1,750 MWh/yr → ~615 t operational + ~150 t/yr embodied |
| +(order 500 servers) ≈ **~750 t CO₂e/yr ≈ 75 g per member per year**, or |
| +roughly **20–30 joules per message**. |
| + |
| +### The ratio |
| + |
| +| comparator | ratio | |
| +|---|---| |
| +| A lean Rails shop (37signals-grade, no K8s) | ~10–15× | |
| +| A typical enterprise K8s deployment | ~30–60× | |
| +| **Central estimate** | **~30×** | |
| + |
| +## Where the ~30× comes from |
| + |
| +The advantage is multiplicative across mostly-independent factors — which |
| +is why it's large, and why no single optimization on the Rails side closes |
| +the gap: |
| + |
| +| factor | ~multiplier | why | |
| +|---|---|---| |
| +| Runtime: compiled Go + in-process SQLite vs Ruby/Puma + network-hop DB | 4–8× | a Puma worker is 500 MB–1 GB vs ~23 MB for an *entire instance*; language-energy studies (Pereira et al., SLE 2017) put Ruby at ~20× Go on CPU-bound work | |
| +| Scale-to-zero vs provision-for-peak | 2–4× | ~90% of spaces cost nothing at any moment; the multi-tenant fleet idles 24/7 at 20–30% utilization | |
| +| No control plane / sidecars / observability tax | 1.3–1.7× | the "orchestrator" is an activator + an S3 lease — a rounding error, not a node pool | |
| +| No hot database + cache + search tier | 1.5–2× | the database tier is often a third of a Rails fleet; here it's a file inside each process, and cold ones are parked ciphertext | |
| +| E2EE forecloses server-side work | 1.2–2× | no indexing, analytics, ML pipelines, image proxying, or transcoding — structurally impossible, not just declined; even image downscaling happens on the client | |
| + |
| +The last row is the quiet one: E2EE is usually costed as a *constraint*. |
| +In carbon terms it's a subsidy — every feature the server can't see is a |
| +feature the server can't burn watts computing. |
| + |
| +## What this estimate is not |
| + |
| +Honesty section, in the spirit of the siblings: |
| + |
| +- **Hibernation is the entire trick.** The marginal cost of an *idle* |
| + tenant actually favors multi-tenant — kilobytes of Postgres rows versus |
| + ~23 MB warm. Process-per-tenant *without* scale-to-zero would be worse |
| + than Rails, not better. If duty cycle approached 100%, the advantage |
| + shrinks toward just the runtime factor (~5–10×). |
| +- **Grid intensity can dominate everything.** A Rails app on a |
| + market-based-zero renewable contract versus this stack on a coal grid |
| + inverts the operational numbers. Embodied carbon — ~10 servers versus |
| + ~500 — favors the small fleet regardless of who signs which PPA. |
| +- **AI inference isn't counted.** Heavy LLM use by the bot sidecars would |
| + dwarf either infrastructure's footprint — and applies to both models |
| + equally, so it cancels out of the ratio and dominates the absolutes. |
| +- **Client-side work moves joules, it doesn't create many.** Crypto and |
| + image downscaling run on members' devices; the marginal energy per |
| + message on a phone is micro-joules against a battery already being |
| + spent on the screen. |
| +- **The comparator is a plain chat app.** A real product messenger with |
| + search, analytics, growth infrastructure, and data pipelines would widen |
| + the gap further; this comparison deliberately gives Rails the benefit of |
| + doing only what Eleven does. |
| + |
| +## The one-sentence version |
| + |
| +**~2 g versus ~75 g CO₂e per member per year — the difference between an |
| +infrastructure that sleeps when its members do, and one that idles at peak |
| +provisioning forever.** |
| + |
| +## Sources |
| + |
| +- [Cloud Carbon Footprint — methodology & coefficients](https://www.cloudcarbonfootprint.org/docs/methodology/) |
| +- [37signals' cloud-exit hardware (4,000 vCPUs / 7.7 TB RAM)](https://world.hey.com/dhh/the-hardware-we-need-for-our-cloud-exit-has-arrived-99d66966) |
| +- [Pereira et al., *Energy Efficiency across Programming Languages* (SLE 2017)](https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf) |
| +- [Datadog Container Report — utilization findings](https://www.datadoghq.com/container-report/) |
| +- [AWS sustainability — fleet PUE](https://sustainability.aboutamazon.com/products-services/aws-cloud) |
| +- [IEA — global electricity carbon intensity](https://www.iea.org/energy-system/electricity) |
| +- Live fleet measurements: production router box, 2026-07-11 (per-unit |
| + RSS via systemd; 15 warm instances + 4 services + 5 sidecars ≈ 550 MB, |
| + load 0.21 on 2 ARM vCPUs) |
| +- The plan: [#550 — planet-scale over S3](https://github.com/elevenmessenger/messenger/issues/550) |
| + |
| +*Snapshot as of July 2026 — coefficients and grids move; re-measure before |
| +quoting.* |
amadan