A decade of chasing simpler metrics

Trifle started as a Rails plugin that hooked into ActiveSupport::Notifications to collect performance data from every request: controller actions, template rendering, database queries. The first dashboard was a proof of concept: a Rails app with some JavaScript charts. It worked. Barely.

Jozef and Lubomir Herko, a fellow developer and the co-founding member of the team, applied to WebSummit together and got accepted as an Alpha Startup. The conference itself was a blur, but by the end every startup walked away with $12,000 in Google Cloud credits. That bankrolled the next phase.

Processing millions of requests meant 90,000+ objects just to render a 3-hour chart. The solution: aggregate values into time-bucketed statistics. Per-minute, per-hour, per-day. MongoDB's upsert with atomic increment made writes blazingly fast. No row locks, no confirmation needed.

PerformanceHour.collection.bulk_write([{
  update_many: {
    filter: { app_id: id, finished_at: timestamp },
    update: { '$inc' => { time: 152.33, count: 15 } },
    upsert: true
  }
}])

This pattern, upsert with increment into time-bucketed keys, became the foundation of everything Trifle is today.

A new beta tester plugged in their scraping application at 10PM. It was a night of heavy crawling. The queue climbed to half a million, then a million, then 3.5 million jobs. Between midnight and 3AM, Jozef learned the hard way about read replicas, connection pooling, and why you don't onboard clients before bed. The queue eventually drained by lunchtime. Lesson learned: scaling is not just about spinning more servers.

When the Google Cloud credits ran out, the APM shut down. But the core idea survived. The problem was never collecting performance data. It was that the architecture tried to do too much. The next version would be simpler. Not a performance monitor. A way to answer questions from your statistical data using the database you already have.

The rewrite found its first real-world test in a hobby project: a home weather monitoring station built from Raspberry Pis with environmental sensors. Temperature, humidity, pressure, all piped into Trifle's API to collect data and build statistics. It was a small use case, but it proved the new architecture worked. Simple, composable, no fuss.

A new browser automation project needed analytics, but adopting a third-party service felt wrong. Instead, all those years of learnings were distilled into two open-source Ruby gems: Trifle::Stats for time-series metrics across Redis, PostgreSQL, and MongoDB, and Trifle::Traces for structured execution tracing. No proprietary API, just libraries you add to your app.

The same pattern, upsert with increment into time-bucketed keys, turned out to be language-agnostic. Trifle::Stats was ported to Elixir and then Go. Three languages, same simple idea, same composable approach. Learning functional programming paradigms along the way.

The libraries were always the core. But developers wanted dashboards, alerts, and a way to query metrics from the terminal. So Trifle grew into a platform: Trifle App for dashboards and automations, Trifle CLI for terminal access and AI agent integration via MCP, and the open-source Stats libraries for Ruby, Elixir, and Go.