At Metronome, we know firsthand how challenging it can be for engineers to implement and scale billing systems. Whether you’re relying on spreadsheets or ad-hoc scripts, manual billing quickly becomes a bottleneck as a company grows. But when you’re just starting out with a lean team and a handful of key customers, the focus is velocity over scalability. Like Paul Graham says, sometimes you have to do the unscalable before you can scale. 

The irony isn’t lost on us: who runs a company that’s focused on making billing easier but hasn’t fully stood up that functionality in their own organization? Like many of our clients, our engineering team is focused on shipping features for our customers—not on building our internal billing. As an engineer here at Metronome, it was enlightening when the time came for us to turn our attention to getting our own billing house in order. Enter: Metronome on Metronome.

Hi, I’m Nicholas, an engineer on the Product Platform team at Metronome. I’ll walk you through my experience with implementing Metronome—how we integrated it into other systems, highlighting key lessons that might help other engineers tasked with billing challenges. This transition was straightforward, saved us time, and even helped us improve our product along the way.

Drinking our own champagne

Metronome itself is a usage-based company. Our key products include real-time event ingestion, flexible pricing for invoicing, and usage alerts. As we onboarded more customers and grew rapidly, we encountered the same pain points our customers face: billing became more complex, invoice generation took longer, and our sales and finance teams needed better insights into client usage.

We care deeply about the customer experience, and that includes giving clients real-time visibility into their usage and bills. Questions like “What will my bill be this month?” or “Will I exceed my commit?” became more frequent, and we needed a solution that could scale seamlessly while enabling proactive customer communication.

Using Metronome internally let us automate our billing workflows and reduce manual errors. Just as importantly, it gave us valuable insights into our own product, allowing us to refine the customer experience and enhance features based on firsthand experience.

Architecting for scale

Integrating Metronome into our own systems required a structured approach to ensure minimal disruption to invoicing. To do this, we focused on two key areas:

1. Understanding our invoices: We mapped out our existing invoices to determine how we wanted to structure our usage events.
2. Emitting usage data: We looked at our data pipeline to determine the best way to emit those events efficiently.

This approach helped us design a flexible architecture that could adapt to future pricing and packaging changes.

Designing the usage events

Each line item on an invoice corresponds to a single billable metric. One of our primary pricing metrics is the number of events ingested. For instance, the "Events Ingested" line item maps to the events_sent metric, which tracks the number of events clients send. This approach of designing events based on existing invoices worked well for us as we already had established products, although Metronome is designed to enable flexible invoicing regardless of the initial data stream.

Here’s an example of the usage event schema we designed:

{
 "timestamp": "2025-01-06T04:58:52.969000+00:00",
 "transaction_id": "9e177c9f-748e-455e-bd25-a81cacacfa14",
 "customer_id": "b282ae0b-ff05-49dd-a7af-e2f4f1f5591a",
 "event_type": "events_sent",
 "properties": {
   "events_sent": "3747334",
   "environment_type": "PRODUCTION",
   "is_duplicate": false
 }
}

Architecture

Our integration was designed to be scalable and resilient. The key components include:

• Metrics emission: Instrumenting services to emit raw usage metrics
• Usage collection: Aggregating raw metrics into usage events
• Reporting to Metronome: Using Metronome’s API to report usage data efficiently

Metrics emission

For some event types, we leveraged existing metrics, like the events_sent metric already stored in a database. For other events, we had to create pipelines to record raw metrics. We were able to leverage a separate engineering effort, dubbed our durable events pipeline, to record raw metrics for a number of events. The durable events pipeline provided a low-cost way to record custom raw metrics and query them via SQL efficiently.

Usage collection

Once we had raw metrics, we processed them into usage events through aggregation and normalization. For example, this simple SQL query helped us batch process events_sent efficiently:

SELECT
 customer_id,
 SUM(events_sent) AS events_sent
FROM
 events
WHERE
 timestamp >= '2024-10-01'
 AND timestamp < '2024-11-01'
GROUP BY
 customer_id

We set up a cron cadence to execute the query and then send them to an intermediary queue for final processing and reporting to the Metronome API.

Reporting to Metronome

We reported usage events to Metronome using an intermediary queue with retry logic. Following our best practices, we implemented exponential backoff for failed requests and a Dead Letter Queue (DLQ) for persistent failures. This ensured reliability and prevented data loss.

Future-proofing

Our internal architecture was designed with future growth in mind. When we introduce a new product, all we need to do is add another usage collector to capture and process its specific metrics. By keeping the architecture extensible, we can quickly adapt to new product lines and pricing models with minimal engineering effort.

How it changed our operations

Integrating Metronome into our internal systems has really been a game changer, enhancing both our product quality and operational efficiency. We’ve been able to give honest feedback on our product and move toward proactive usage monitoring.

Enhanced product feedback

Experiencing our product firsthand surfaced many areas for improvement. For example, while setting up contracts, we refined the workflow to reduce friction—making it even more intuitive and easier to self-serve. Additionally, internal usage highlighted the importance of features like SQL billable metrics, which we prioritized in our Metronome 2.0 launch.

Operational efficiency

Automating the invoice generation process eliminated manual invoicing, saving tens of hours per month for our finance team while ensuring accuracy. Previously, our finance team had to manually run queries, which was both time-consuming and required manual review to ensure accuracy. Now, they can focus on strategic initiatives instead of running SQL queries.

Real-time insights have also allowed us to shift to proactive customer communication. With the updates we made here, we can now notify clients about usage spikes in advance, leading to better transparency and trust.

Usage-based billing is inherently complex– from tracking granular usage data to ensuring accurate invoicing. Many engineering teams struggle with scaling their billing processes. But by implementing Metronome internally, we streamlined our billing operations and turned a traditionally complex, time-consuming task into something far more manageable.

If you're tackling similar billing challenges, we’d love to help. Reach out to us with questions, challenges you’re thinking through, or to just nerd out on billing together.