What is Unimeter

If you just landed here from the home page, welcome. This page is the longer introduction for anyone deciding whether Unimeter is the right tool for their situation. If you already know it is and want to get hands-on, jump to the Quickstart.

If you sell software or services and need to charge customers based on what they actually use, you need a way to count that usage reliably. Every API call, every gigabyte transferred, every active seat, every minute of compute. Unimeter is the piece of software that does this counting for you.

You send it events, one by one or thousands at a time. Unimeter stores them safely on disk, groups them by customer and by billing period, and keeps a running total that your application can ask about at any moment. When the month ends and you need to generate invoices, you query Unimeter and get exact numbers back in a few milliseconds.

Why you might want this

Building a usage metering system inside your own application sounds simple until you actually try. You need to handle millions of events without dropping any. You need to survive a server crash without losing the last hour of usage. You need to query totals quickly even when a single customer has generated ten million events this month. You probably want to alert yourself when a customer crosses a threshold, like exceeding their free tier. And you want all of this to keep working when your traffic grows.

Unimeter exists so you do not have to build any of that yourself. It is designed from the ground up for high throughput and for correctness, which means your usage counts match reality and invoices come out right.

What it gives you

When you send an event to Unimeter, you get a receipt telling you it was stored safely. Events are persisted to disk and replicated to other nodes in your cluster before Unimeter confirms receipt, so a crash right after the confirmation cannot lose the event. When you ask how much a specific customer has used this month, Unimeter answers in about a millisecond because it keeps the running totals in memory.

The system is clustered by default. You run three or more nodes, they coordinate automatically, and if one dies the others keep accepting events without dropping traffic. You do not need a separate database, message broker, or orchestration system. Unimeter is a single compiled binary that speaks a compact binary protocol over TCP.

For your application code, you talk to Unimeter through a client library. The Go library exists today and handles all the networking details for you. You call client.Ingest to record events, client.Query to read back totals, and that is almost the entire surface area you need to know.

Is this the right tool for your situation

Unimeter is a good fit when your pricing depends on how much customers use your product and you need those numbers to be correct. Think of per-call API billing, per-gigabyte storage fees, seat-based subscriptions with mid-cycle changes, or anything similar. It also works well when you need usage data for internal dashboards and you want one source of truth for how much each customer is doing.

It is probably not the tool you want if your product has a simple flat subscription and you only need to know whether the customer is active or not. A boolean in your existing database is cheaper. It is also not a full billing platform. Unimeter tells you how much was used, but you still need something like Stripe or a home-grown system to turn those numbers into invoices, charge cards, and manage subscriptions. The two fit together naturally though.

Next step

Head to the Quickstart to run Unimeter on your machine and record your first event. It takes about five minutes.