When engineering teams consider how best to report usage records—whether directly to their database (or billing provider) or through a dedicated metering system like OpenMeter—they're faced with two key considerations:
- Usage volume
- Use cases building on aggregated usage
Collecting usage is mainly driven by the nature of your business; for example, AI and DevOps companies will generate more usage data, posing engineering challenges. Meanwhile, usage consumption use cases primarily depend on the stage of your product. Early-stage products first focus on billing, then expand to broader, more complex usage data requirements that span the company from engineering to product, sales, and finance, requiring a flexible usage data source and integrations.
1. Assessing Usage Volume
Let's focus first on the data ingestion side of metering. With usage-based pricing models, you must record every billable event in your system. The volume of these events depends on your business, customers, and pricing model. For example, a company charging after every API call or AI token usage likely must track millions of events from the early days of business, and they will run into scaling issues quickly as their customer base grows.
This can lead to expensive database bills or rate limits if you directly report raw usage to Stripe. This is especially true with traffic spikes and bursty load. Let's see common data ingestion use cases with their metering requirements:
| Usage Collection Use Cases | Metering Requirements |
|---|---|
| Usage-based billing | Accurate usage collection |
| Growing company scale | Cost-effective data ingestion |
| Traffic and usage spikes | Capturing all events without rate limits |
| Retries and network errors in distributed systems | Event deduplication |
| Extracting usage from infrastructure | Collectors and SDKs |
To summarize, when it comes to ingesting billable events, the primary consideration is volume. If you anticipate a larger scale of product consumption, reporting usage directly will not be sustainable, and you need an external metering system that can scale without breaking the bank.
2. Exploring Usage Data Use Cases
In a usage-driven company, you will consume the aggregated and metered consumption data in multiple functions, from product to sales and finance. These use cases have different volume, latency, and integration data requirements. If you use, for example, your billing provider directly to aggregate usage and this way, it becomes the source of truth for your metered usage, you will run into scenarios where you get restricted by their APIs, latencies, and rate limits. Let's look at some of the common use cases where you potentially need to read metered usage:
| Usage Read Use Case | Data Requirements |
|---|---|
| Billing from meters | Robust reporting to the billing provider |
| Customer consumption dashboards | Instant meter aggregations |
| Enforcing usage and rate limits | Low-latency data access |
| Providing data to sales | Integration with Salesforce and CRMs |
| Cost and unit economics calculations | Flexible usage querying |
| Forecasting and budgeting | Data retention |
In summary, some usage data use cases require flexible query language, higher rate limits, and low latency data access. Consider the use cases above when you decide where to store your usage data.
Alternatives
Finally, let's compare the most common solution to collect and consume usage data without a dedicated metering system:
| Solution | Common challenges |
|---|---|
| Online databases (Postgres, etc.) | Cost and performance issues at scale |
| Billing providers (Stripe, etc.) | Rate limits and query inflexibility |
| OLAP (ClickHouse, etc.) | Pre-ingest event batching necessity |
| Data warehouses | Delayed aggregation due to batch processing |
| Streaming aggregation (Flink, etc.) | Development and maintenance complexity |
You can read more on the topic in our previous blog post.
One part of the challenge lies in efficiently collecting and querying usage data and equally important, seamlessly integrating this data across the organization—from billing and CRM systems to finance and engineering departments—to inform and enhance usage-based business models and control costs.
How does OpenMeter help?
OpenMeter provides a robust usage metering solution that handles the load, usage spikes, and duplicates required to implement accurate usage-based billing. It provides instant aggregates on meters with low latency to access your usage data and power your team's metering data requirements.
At the same time, OpenMeter can continuously report aggregated usage to Stripe and other payment providers with an exactly-once guarantee. OpenMeter was built with experience working at Stripe, Netflix, IBM, and Cisco to serve your metering needs.
