Next Applications: Eight Places Where Answers Kept Ready Could Fit

The four case studies share one pattern. The questions are known in advance and the events arrive as a stream, so the answers can be kept current as each event lands, while raw detail stays only as long as it is useful. API monitoring, market data, usage billing and logs came first because the demos cover them.

The pattern turns up in many more places. None of the eight below has been tested, and none runs Precomputing today. This post sets out what each would ask of the platform, and which parts already carry over from the demos. It is a map for choosing pilots, ideally together with the people who run these systems.

Eight applications with the same pattern as the demos. None of them has been tested.

What They Would Share

• Answers in a lookup. Dashboards, invoices and limits read a ready row instead of scanning events.
• Files that grow with time. A summary costs the same at ten events a minute or ten thousand.
• Exact where money is involved. Exact streams count each billable event once and close their periods.
• Raw data on your own machines. Detail stays as long as the policy says, where you decide, and unusual events stay whole.

Per-Tenant Dashboards

SaaS products that give each customer their own SQLite database, such as Cloudflare Durable Objects.

A product with one database per tenant still wants a usage dashboard per tenant: requests, errors, active users and p95 by feature. Today that usually means shipping events to a separate analytics store. With the compiled SQL in each tenant’s own database, the answers live beside the tenant’s data and fade on the same schedule. Cloudflare’s SQLite-backed Durable Objects are one place this could run.

• Carries over: Demo 1’s policy almost as it is, and the compiled SQL, which needs nothing but SQLite.
• New work: measuring what the triggers add to each write in that setting, and keeping a policy small enough for thousands of tenants.

In-App Analytics

Usage statistics kept on phones or in the browser.

An app that wants to know how it is used can keep its own statistics in the SQLite it already has, and send home only summaries. The detail never leaves the device, which suits apps that care about privacy, and the summaries are small.

• Carries over: the SQL runtime runs in SQLite wherever it runs; Demo 1 already runs in a browser tab.
• New work: merging summaries from many devices into one view, which the file format was designed for but 0.1 does not do yet.

An API Sidecar

Requests, errors and p99 per route, next to a service, with no metrics stack.

A small team running a few services may not want a metrics system to answer its first questions. A sidecar Engine takes events over HTTP from the service beside it and serves the answers back: per route, per minute, with slow requests kept whole.

• Carries over: Demo 1’s policy on the Engine, and precomputing serve with its HTTP API.
• New work: authentication for the HTTP server, planned for 0.2, and answers in a form existing dashboards read.

Game Servers

Live match stats and leaderboards, with raw events fading after a day.

A game server produces a stream of events per match: kills, scores, purchases, disconnects. Players want live stats and leaderboards; the studio wants daily summaries and unusual events for review. Raw events matter for a day at most.

• Carries over: the Engine’s speed, per-day precomputes like Demo 2’s quote board, and anomalies that keep unusual events whole.
• New work: memory and start-up time with millions of players as keys, and leaderboards that stay cheap to read at that size.

An API Product With Plans per Key

Included usage, overage and rate plans, per API key.

An API product sells plans: a number of calls included each month and a price for each call beyond them, usually with a rate limit on top. Every call must be counted once, whichever server took it, and the limit must be checked before serving.

• Carries over: Demo 3’s meter as it is: exact streams, retries refused by id, monthly quotas read in microseconds.
• New work: overage pricing in the billing views, and per-minute rate limits, which 0.1 quotas do not cover because their periods are hours, days and months.

Internal Chargeback of AI Spend

Budgets and spend per team, kept exact.

A company that uses AI models across many teams wants to know who spent what, and to stop a team at its budget. The numbers go to finance, so they have to be exact and they have to close each month.

• Carries over: the meter counting tokens by team and model, quotas as budgets, and months that close.
• New work: prices that change during a month, and reports in the formats finance teams use.

A Kubernetes Cluster With Noisy Health Checks

Repeats collapse into templates while errors stay whole.

A cluster writes a great many lines that say the same thing, such as health checks and routine access lines. Paying to index them is the expensive part of many log bills. Templates count them in one row per minute, while errors and new kinds of line go upstream whole.

• Carries over: Demo 4’s templates, its error lines kept whole, and every line kept on site for search.
• New work: JSON log lines and a plug-in for the OpenTelemetry Collector, both planned for 0.2, and fields such as namespace and pod read from the log metadata.

Branch Offices on Thin Links

Answers and anomalies travel; raw logs stay on site.

Shops and clinics often send their logs over links that are slow or costly. Sending a dashboard’s answers instead of every line makes the link matter much less, and the raw lines stay searchable on site when someone needs them.

• Carries over: Demo 4’s upstream batches, 120 times smaller than the lines, and the search over lines kept on site.
• New work: a forwarder that sends batches in order across outages, using the sequence numbers the Engine already keeps, and one dashboard for many sites.

Where to Start

Each application above maps to one part of the platform that already works in a demo, plus some new work. The roadmap takes care of the shared gaps first: the forwarder, JSON lines and authentication. Teams working in any of these areas are welcome to get in touch about a pilot.