Architect real-time usage-based billing for a PLG company
This tests event-driven metering, idempotent aggregation, and pricing decoupling at scale. A strong answer outlines real-time ingestion, stream processing for micro-events, a rules-based pricing engine, and dashboards with reconciliation.
What's really being asked
This question evaluates whether you can architect revenue-critical infrastructure that bridges high-velocity product telemetry with financial accuracy. Interviewers want to see that you understand the difference between observability metrics and billable events, and that you know how to build idempotent, auditable pipelines that scale to millions of micro-events per day without losing customer trust.
The full answer
First, an event ingestion layer that accepts billable events with strict schema validation, customer attribution, and timestamping. Second, a stream processing tier using something like Kafka or Flink to aggregate raw events into billable units in near real-time, handling different aggregation strategies such as sum, unique count, or latest value. Third, a pricing engine decoupled from usage collection that maps aggregated units to pricing rules including tiers, prepaid credits, and entitlements without requiring code changes. Fourth, a user-facing dashboard that reads from pre-aggregated usage tables to show current spend without hitting the raw event stream. Fifth, a reconciliation and correction pipeline that handles late events, duplicates, and retries so invoices remain accurate.
The mistakes people make
Proposing to query a production OLTP database directly for billing counts. Suggesting nightly batch jobs when the prompt asks for near real-time. Ignoring idempotency and assuming events arrive exactly once. Hardcoding pricing logic into the aggregation layer so every pricing change requires a deploy. Overlooking the need for audit trails and double-entry reconciliation between usage and revenue.
What usually comes next
How would you handle a pricing change mid-month for existing customers? What happens if a customer disputes a bill and you need to reconstruct their usage? How do you prevent a surge in API calls from overwhelming the billing pipeline? How would you model prepaid credits that draw down in real time?
A concrete example
Imagine a PLG company charging per GB of storage and per API call. Every upload or API request emits a validated event to a streaming bus. Flink windows aggregate API calls by customer hourly and compute storage deltas from upload and delete events. The pricing engine applies a tiered rate for API calls and a per-GB rate for storage, then writes the running totals to a read-optimized store. The dashboard polls this store to show today's spend. At month end, a reconciliation job compares the aggregated totals against a cold storage archive of raw events to catch duplicates or gaps before invoicing.
Interview question
When designing a revenue-critical billing pipeline that aggregates millions of micro-events, which approach best ensures both real-time spend visibility and financial accuracy?
- a.Pre-aggregate events into billable units via stream processing, expose running totals through a read-optimized store for dashboards, and reconcile against cold-stored raw events before invoicing.Correct
- b.Apply pricing rules directly inside the stream processor so each event is immediately converted to a charge, then emit real-time invoices without separate reconciliation.
- c.Process all micro-events in nightly batch jobs to ensure idempotency and accuracy, then update customer spend in a daily pricing engine run.
- d.Query the production OLTP database directly for live usage counts and generate invoices from the same transactional tables to guarantee consistency.
Why? this is the answer
This design gives users near real-time spend data from a dedicated read store while preserving financial accuracy through a final reconciliation step against immutable raw events. Querying the production OLTP directly is a common anti-pattern because it couples billing to application load and provides no auditable revenue trail.
Just read this? Test yourself on what you have been reading.
Read the original → flexprice.io
- #usage-based billing
- #event streaming
- #pricing architecture
- #system design
- #plg
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles