FastAPI Backend Development Bootcamp · Lezione

Misurazione dell’utilizzo, quote e hook di fatturazione

Tracci l’utilizzo per tenant, applichi le quote del piano ed emetta eventi di fatturazione per prezzi SaaS basati sul consumo.

Lezione 4 di 413 passaggi

Misurazione dell’utilizzo, quote e hook di fatturazione è una lezione FastAPI Backend Development Bootcamp gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento FastAPI Backend Development Bootcamp, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso FastAPI Backend Development Bootcamp include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

Why Metering Matters in SaaS

In a multi-tenant SaaS, every tenant shares the same FastAPI app but pays based on what they actually use. To support plans like Free / Pro / Enterprise you need three cooperating subsystems:

  • Metering — count consumed resources (API calls, tokens, rows, GB).
  • Quotas — block or throttle once a tenant exceeds its plan limit.
  • Billing hooks — emit events that downstream billing (Stripe, etc.) turns into invoices.

The hard part is doing this per tenant, accurately, and without adding latency to every request. We will build each piece in this lesson.

Modeling Plans and Quotas

Start by modeling what each plan allows. A plan maps a metric (what we count) to a limit and a period (when the counter resets). Keeping this as plain data makes it easy to load from a DB or config.

Below, a metered plan tracks API requests and AI tokens with monthly limits. None means unlimited.

from dataclasses import dataclass

@dataclass(frozen=True)
class Quota:
    metric: str
    limit: int | None   # None = unlimited
    period: str          # 'day' or 'month'

PLANS = {
    "free": [Quota("api_calls", 1_000, "month"), Quota("ai_tokens", 50_000, "month")],
    "pro": [Quota("api_calls", 100_000, "month"), Quota("ai_tokens", 5_000_000, "month")],
    "enterprise": [Quota("api_calls", None, "month"), Quota("ai_tokens", None, "month")],
}

def limit_for(plan: str, metric: str) -> int | None:
    for q in PLANS[plan]:
        if q.metric == metric:
            return q.limit
    return 0  # metric not allowed on this plan

print(limit_for("free", "api_calls"))   # 1000
print(limit_for("enterprise", "ai_tokens"))  # None (unlimited)
print(limit_for("free", "unknown"))     # 0

An Atomic Usage Counter

The core of metering is a counter you can increment atomically per (tenant, metric, period). In production this is usually Redis (INCRBY + EXPIRE) or a Postgres UPSERT with an atomic +=.

Here is the concept modeled in pure Python so you can see the key and the increment logic. The period key (e.g. 2026-06) is what makes the counter reset every month automatically.

from collections import defaultdict
from datetime import datetime, timezone

usage = defaultdict(int)

def period_key(period: str, now: datetime) -> str:
    if period == "month":
        return now.strftime("%Y-%m")
    return now.strftime("%Y-%m-%d")

def incr(tenant: str, metric: str, amount: int, period: str, now: datetime) -> int:
    key = (tenant, metric, period_key(period, now))
    usage[key] += amount
    return usage[key]

now = datetime(2026, 6, 10, tzinfo=timezone.utc)
print(incr("acme", "api_calls", 1, "month", now))  # 1
print(incr("acme", "api_calls", 1, "month", now))  # 2
print(incr("acme", "ai_tokens", 1200, "month", now))  # 1200

Enforcing a Quota

Quota enforcement combines the plan limit with the current counter. The decision is simple but the order matters: you usually want to check-then-increment so that a request that would exceed the limit is rejected before doing the work.

For atomicity in real systems you increment first, then compare against the limit, and if you went over, you reject and optionally decrement (or simply let the counter sit over-limit, blocking further calls).

def check_quota(current: int, amount: int, limit: int | None) -> bool:
    """Return True if `amount` more units are allowed."""
    if limit is None:
        return True  # unlimited
    return current + amount <= limit

print(check_quota(995, 1, 1000))    # True  (996 <= 1000)
print(check_quota(1000, 1, 1000))   # False (1001 > 1000)
print(check_quota(9_000_000, 1, None))  # True (unlimited)

Wiring It Into FastAPI with a Dependency

In FastAPI the clean place to enforce quotas is a dependency. It resolves the tenant (from auth/JWT), looks up the plan, checks the quota, and raises HTTPException(429) when the limit is hit.

Returning 402 Payment Required is also common for hard plan caps, while 429 Too Many Requests fits rate-style limits. This is framework code, so it is not standalone-runnable.

from fastapi import Depends, HTTPException, Request

async def enforce_quota(metric: str, cost: int = 1):
    async def _dep(request: Request):
        tenant = request.state.tenant_id
        plan = await get_plan(tenant)
        limit = limit_for(plan, metric)
        current = await store.get(tenant, metric, "month")
        if not check_quota(current, cost, limit):
            raise HTTPException(
                status_code=429,
                detail=f"Quota exceeded for {metric}",
                headers={"X-Quota-Limit": str(limit)},
            )
        await store.incr(tenant, metric, cost, "month")
        return current + cost
    return _dep

@app.post("/v1/complete")
async def complete(used=Depends(enforce_quota("ai_tokens", cost=500))):
    return {"ok": True, "tokens_used_this_month": used}

Metering AFTER the Work for Variable Costs

Some costs are not known up front. AI token usage, bytes processed, or rows returned are only known after the handler runs. For these, do a cheap pre-check (is the tenant already over?) and record the real cost afterward.

A reliable pattern is a context manager that admits the request, runs the body, then reports actual usage — even on exceptions, so you don't lose metering data.

from contextlib import contextmanager

@contextmanager
def meter(record, tenant, metric):
    actual = {"amount": 0}
    try:
        yield actual            # caller sets actual['amount']
    finally:
        if actual["amount"]:
            record(tenant, metric, actual["amount"])

log = []
with meter(lambda t, m, a: log.append((t, m, a)), "acme", "ai_tokens") as use:
    # ... do real work, then we learn the true cost ...
    use["amount"] = 1342

print(log)  # [('acme', 'ai_tokens', 1342)]

Soft Limits, Hard Limits and Overage

Real billing rarely flips from 'works' to '403' at exactly the limit. Plans usually define:

  • Soft limit — allow but warn (email, X-Quota-Warning header) around ~80%.
  • Hard limit — block once exceeded (Free plans).
  • Overage — keep serving but bill each extra unit at a metered rate (Pro/Enterprise).

Encode this as a policy so the enforcement code stays declarative.

def classify(current: int, limit: int | None, overage_allowed: bool) -> str:
    if limit is None:
        return "ok"
    if current < 0.8 * limit:
        return "ok"
    if current < limit:
        return "warn"
    return "overage" if overage_allowed else "blocked"

print(classify(700, 1000, False))   # ok
print(classify(850, 1000, False))   # warn
print(classify(1200, 1000, True))   # overage
print(classify(1200, 1000, False))  # blocked

Emitting Billing Events

Metering produces a stream of usage events. Billing systems (Stripe Billing Meters, Orb, Metronome) consume these to compute invoices. The golden rules for billing events:

  • Include an idempotency key so retries don't double-charge.
  • Carry a timestamp so events land in the correct billing period.
  • Make them immutable — append-only, never edit.

Build the event payload as a plain, serializable record.

import uuid, json
from datetime import datetime, timezone

def billing_event(tenant: str, metric: str, qty: int, ts: datetime, request_id: str) -> dict:
    return {
        "id": str(uuid.uuid4()),
        "idempotency_key": f"{tenant}:{metric}:{request_id}",
        "tenant_id": tenant,
        "metric": metric,
        "quantity": qty,
        "occurred_at": ts.isoformat(),
    }

evt = billing_event("acme", "ai_tokens", 1342,
                    datetime(2026, 6, 10, tzinfo=timezone.utc), "req_9f3")
print(json.dumps(evt, indent=2))

Decoupling with a Background Queue

Never call your billing provider synchronously inside the request path — a slow or down Stripe API would break your API. Instead, write the usage event to a durable buffer and flush it asynchronously.

FastAPI's BackgroundTasks works for low volume; for real scale use an outbox table, Redis stream, or a worker (Celery/ARQ). The handler stays fast; a separate consumer ships events to billing with retries and idempotency.

from fastapi import BackgroundTasks

@app.post("/v1/complete")
async def complete(bg: BackgroundTasks, request: Request):
    tenant = request.state.tenant_id
    result, tokens = await run_completion(request)
    await store.incr(tenant, "ai_tokens", tokens, "month")
    evt = billing_event(tenant, "ai_tokens", tokens,
                        datetime.now(timezone.utc), request.state.request_id)
    bg.add_task(emit_to_billing, evt)  # fire-and-forget, off the hot path
    return result

Reconciliation: Trust but Verify

Counters drift. A crashed worker, a lost event, or a Redis flush can desync your metering from reality. Robust SaaS systems treat the append-only event log as the source of truth and periodically reconcile the fast counters against it.

A nightly job re-aggregates raw events per tenant/metric/period and corrects the cached counter. This also lets you regenerate billing if a provider rejected a batch.

from collections import defaultdict

def reconcile(events: list[dict]) -> dict:
    """Rebuild authoritative totals from the immutable event log."""
    totals = defaultdict(int)
    seen = set()
    for e in events:
        if e["idempotency_key"] in seen:
            continue  # dedupe replays
        seen.add(e["idempotency_key"])
        period = e["occurred_at"][:7]  # YYYY-MM
        totals[(e["tenant_id"], e["metric"], period)] += e["quantity"]
    return dict(totals)

events = [
    {"idempotency_key": "acme:t:1", "tenant_id": "acme", "metric": "t", "quantity": 100, "occurred_at": "2026-06-01T10:00:00"},
    {"idempotency_key": "acme:t:1", "tenant_id": "acme", "metric": "t", "quantity": 100, "occurred_at": "2026-06-01T10:00:00"},
    {"idempotency_key": "acme:t:2", "tenant_id": "acme", "metric": "t", "quantity": 50, "occurred_at": "2026-06-02T09:00:00"},
]
print(reconcile(events))  # {('acme','t','2026-06'): 150}

Tenant Isolation and Hot Keys

A few operational rules keep per-tenant metering correct and fast:

  • Always scope the counter key by tenant_id — never share a global counter, or one noisy tenant blocks others.
  • Watch for hot keys: a huge tenant hammering one Redis key can become a bottleneck; shard the key (tenant:metric:shard) and sum on read.
  • Make limit checks fail-open or fail-closed deliberately — if the counter store is down, decide whether to allow (availability) or block (revenue protection).
  • Reset boundaries must respect the tenant's billing-cycle timezone, not just UTC month.

Quick Check

Test your understanding of the metering decision flow.

Recap

You built a complete per-tenant metering and billing pipeline:

  • Plans & quotas as data: metric to limit to reset period, with None for unlimited.
  • Atomic counters keyed by (tenant, metric, period) so limits reset automatically.
  • Enforcement via a FastAPI dependency returning 429/402; check-then-increment for fixed costs, meter-after for variable costs.
  • Policies for soft limits, hard limits, and overage instead of a single hard cutoff.
  • Billing events that are immutable, timestamped, and idempotent, shipped asynchronously off the request path.
  • Reconciliation from an append-only event log as the source of truth, plus tenant-isolation and hot-key care.

With these pieces you can support usage-based pricing safely without slowing down your API.

Gratis per iniziare

Impara FastAPI Backend Development Bootcamp con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi
21
Lezioni
84

Domande Frequenti

La lezione «Misurazione dell’utilizzo, quote e hook di fatturazione» è gratuita?

Sì — il testo completo di «Misurazione dell’utilizzo, quote e hook di fatturazione» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso FastAPI Backend Development Bootcamp, passa a CoddyKit PRO. Il corso FastAPI Backend Development Bootcamp include 4 lezioni in totale.

Cosa imparerò in «Misurazione dell’utilizzo, quote e hook di fatturazione»?

Tracci l’utilizzo per tenant, applichi le quote del piano ed emetta eventi di fatturazione per prezzi SaaS basati sul consumo. Eserciti FastAPI Backend Development Bootcamp con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare FastAPI Backend Development Bootcamp?

Non è richiesta alcuna esperienza precedente. FastAPI Backend Development Bootcamp su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Misurazione dell’utilizzo, quote e hook di fatturazione»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione FastAPI Backend Development Bootcamp?

Sì. Ogni lezione FastAPI Backend Development Bootcamp include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Strategie di isolamento dei tenant e relativi compromessi
  2. Risoluzione del contesto del tenant e middleware
  3. Sicurezza a livello di riga e partizionamento dei dati
  4. Misurazione dell’utilizzo, quote e hook di fatturazione
← Torna a FastAPI Backend Development Bootcamp