Usage Metering and Billing Engine for API Products

The problem API products have with usage-based billing

More products charge by usage: API calls, messages sent, minutes transcribed, tokens processed, gigabytes stored. For a small startup this sounds simple until they build it. Events arrive twice when clients retry. Some arrive after the month has closed. Pricing changes mid-month. A customer disputes an invoice and nobody can show which events produced it. Teams end up with a cron job, a SQL query and a spreadsheet, and billing bugs become customer trust problems.

What already exists and the gap

• Lago is an open source metering and usage-based billing platform that can be self-hosted.
• OpenMeter is an open source metering project, acquired by Kong in 2025 and being folded into Kong Konnect.
• Orb and Metronome are hosted usage billing platforms aimed at funded SaaS companies.
• Stripe Billing supports usage-based prices through its metering features.

Mature options exist, so this project is not about finding an empty market. It is about building a smaller, well-understood engine with provable correctness, and pairing it with the local reality many startups face: payment providers that are not available everywhere, so invoices must be generated independently of the processor. As a portfolio piece, few projects show backend depth as clearly.

What you build

Users: the product team integrating the engine (API keys, metric and plan setup), finance (reviews and finalises invoices), and the end customer (sees their usage dashboard).

Flow: the product sends events with a customer ID, event name, timestamp, properties and an idempotency key. The engine stores raw events, maintains running aggregates, applies the customer's plan at period end, and produces an invoice. Anything that happens later becomes an adjustment rather than a silent change.

The technically interesting part

Exactly-once effect over at-least-once delivery. Clients will retry. Deduplicate on idempotency key within a window, store raw events immutably, and make aggregation derivable from raw events. The same principle Stripe uses for idempotent API requests applies here to every usage event.

Aggregation that stays correct and fast. Keeping a running counter is fast but fragile; recomputing from raw events is correct but slow. Build both: incremental aggregates for dashboards, and a recompute path for invoices. Then prove they agree. Unique counts over large sets are a good place to discuss exact counting versus approximate sketches, and to measure the trade-off.

Time. Event time versus arrival time, customer time zones for period boundaries, plan versions that change mid-period, and late events after an invoice is final. Write these rules down as a specification, then test them.

How to evaluate it

• Correctness: a generator creates millions of events with 5 percent duplicates and 1 percent late arrivals. Invoices from the incremental path must equal a from-scratch recompute for every customer.
• Throughput: sustained ingestion rate and 95th percentile ingest latency on one modest machine, measured with k6. Report where it bottlenecks.
• Query speed: dashboard query latency for a customer with 10 million events, before and after pre-aggregation.
• Developer experience: 3 developers integrate the SDK into a sample app; time to first invoiced event and the friction they report.

Suggested plan

1. Weeks 1 to 3: study Lago's and Stripe's public docs on metering, write your own specification of metrics, plans and time rules.
2. Weeks 4 to 8: ingestion API, idempotency, raw event storage.
3. Weeks 9 to 13: metric aggregation, incremental and recompute paths.
4. Semester 2, weeks 1 to 5: pricing engine, plan versions, period close, invoices.
5. Weeks 6 to 9: late events, adjustments, dashboards, SDK.
6. Weeks 10 to 14: correctness and load evaluation, developer study, report.

Path to a product

The realistic first customer is a small API startup or an agency running AI features that bills clients by usage, which cannot yet justify a hosted billing platform. Release the engine as open source and sell a hosted version or support. Alternatively, run your own tiny API product on top of it and let the engine prove itself there.

Scope warning

Do not build payment processing, tax calculation, dunning or a general accounting system. Do not chase distributed streaming infrastructure such as Kafka unless your measurements show you need it. One database done right beats five services done halfway.

Learn what you need on Sefism

• System design roadmap : idempotency, aggregation and time handling at the core of this engine.
• Backend roadmap : API design, auth and data modelling.
• Stripe Documentation : study how metered prices, idempotency keys and invoices are modelled.
• OpenAPI Specification : document the ingestion API properly.
• Grafana k6 Documentation : build the throughput and latency tests.
• Fundamentals of Data Engineering : event time, late data and storage trade-offs.

Get help with this idea

Write the time and pricing specification before any code; it is the part evaluators will question. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session