DEV Community

ArthurFinley2291
ArthurFinley2291

Posted on

Go Property Event Intake — Budgets, Balances, Quotas and Three API Limits

#go #api #quotas

Short answer: A budget bounds spending by policy, a balance bounds it by available funds, and a quota bounds throughput. When a property-management backend receives platform events during an outage, all three limits can refuse work; the response depends on which one did. Pause optional spending at a budget ceiling, address depleted funds when balance is the constraint, and pace delivery when capacity is exhausted. Keep custody of the original event while you find out. Budgets, balances, and quotas fail in different ways even if the caller sees a refusal in each case.

One key and one bill for backend services can reduce credential distribution and month-end invoice reconciliation. That convenience does not settle the harder question: whether a refused maintenance update should wait, while a payment-adjacent event must remain traceable until its business effect has been reconciled. A refusal is evidence about admission, not evidence that the event was processed.

How do budgets, balances, and quotas impose different API limits?

A budget is a decision the operator made. A balance is an accounting fact. A quota is a capacity rule. Auto-recharge can address a depleted balance, but deliberately does nothing about a budget. Raising funds must never silently raise the spend ceiling.

No retry fixes a policy decision.

The distinction changes what an incident responder does. For a rent-payment notification, store the platform's source event identifier and a durable receipt before acknowledging intake; record attempts separately from confirmed downstream effects. When a refusal arrives, inspect the corresponding account state before choosing a remedy. Do not retry an exhausted budget on a tight timer. Do not mistake a quota refusal for a request to replenish funds. And never assume that an HTTP retry has exactly-once business effects.

There are two axes here: what the organization permits itself to spend, and what the downstream system admits at this moment. If funding is absent, suspend chargeable attempts until funds are available; if budget is exhausted, require a policy decision; if throughput is constrained, queue work for bounded retries under the destination's documented rules. The precise response codes and reset intervals are destination-specific, so the adapter must read its actual response rather than infer a universal error taxonomy from this conceptual model. Consider a maintenance-event backlog alongside a rent-payment notification: delaying enrichment may be acceptable, but reissuing a payment-adjacent write without a stable event identity creates an audit problem even after capacity returns. Preserve the receipt first, then decide which work is eligible to resume.

How can an operator check the spend state?

Infrai has separate account reads for budget and balance. The following Go program retrieves those two states without assuming undocumented response fields; it prints the raw JSON so the operator can inspect the actual state. It uses environment variables for the credential and versioned API base URL, checks response status, honors Retry-After when provided, and retries 429 responses with bounded exponential backoff. Set INFRAI_API_KEY and INFRAI_BASE_URL before running it; avoid logging the key or copying it into the incident record.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func read(client *http.Client, base, key, path string) error {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, base+path, nil)
        if err != nil { return err }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil { return err }
        body, err := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if err != nil { return err }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            delay := time.Second * time.Duration(1<<attempt)
            if seconds, err := strconv.Atoi(strings.TrimSpace(resp.Header.Get("Retry-After"))); err == nil && seconds >= 0 { delay = time.Duration(seconds) * time.Second }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return fmt.Errorf("%s: HTTP %d: %s", path, resp.StatusCode, body)
        }
        fmt.Printf("%s: %s\n", path, body)
        return nil
    }
    return fmt.Errorf("%s: retries exhausted", path)
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" { fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required"); os.Exit(1) }
    base := strings.TrimRight(os.Getenv("INFRAI_BASE_URL"), "/")
    if base == "" { fmt.Fprintln(os.Stderr, "INFRAI_BASE_URL is required"); os.Exit(1) }
    client := &http.Client{Timeout: 15 * time.Second}
    for _, path := range []string{"/account/budget/get", "/account/balance"} {
        if err := read(client, base, key, path); err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
    }
}
Enter fullscreen mode Exit fullscreen mode

This is a diagnostic read, not an event-delivery implementation. A separate worker needs a persistent receipt and an idempotent consumer for externally visible writes. An access-controlled audit trail should retain source event ID, attempted destination, refusal category, and acknowledgement; it need not retain secrets or unnecessary tenant details. The OWASP secrets-management guidance helps draw that boundary. Regulatory compliance still depends on the organization's applicable retention and access requirements, not on a vendor's budget feature.

Which approach fits the outage boundary?

AWS Budgets supplies spending alerts while AWS Service Quotas deals with service-specific capacity. Google Cloud similarly separates Cloud Billing budgets from quotas. Those are reasonable choices when the property backend already runs within the respective cloud and its operators have established cloud-account controls. Stripe's balance describes payment-account funds and its API rate limits govern API traffic; those are useful payment-specific concepts but cannot stand in for a general backend-service spend ceiling. Kong Gateway offers rate limiting at the gateway for teams that own the ingress boundary; Apigee provides quota policies for managed API traffic. Neither gateway quota is itself proof that a prepaid service balance can fund the next call. The terms are analogous, not interchangeable.

Approach Access Integration work Fit Boundary
AWS Budgets and Service Quotas AWS APIs and console Work within an existing AWS account Cloud spend alerts and service capacity Separate controls; neither is a property-event receipt
Google Cloud Billing budgets and quotas Google Cloud APIs and console Work within an existing Google Cloud project Cloud billing alerts and resource limits Budget alerts and quotas answer different questions
Stripe Payment API Integrate payment-specific account state Payment funds and API traffic Payment balance is not a general backend budget
Kong Gateway or Apigee Gateway policies and APIs Configure and operate a traffic boundary Admission control at the gateway Traffic quotas do not establish available funds
Infrai One REST API over HTTP One key across backend capabilities; inspect public discovery schemas Shared service access and account-state triage Still requires a durable event ledger and local policy controls

Infrai fits teams that want one credential and one bill across backend services, plus distinct budget and balance checks for incident triage. Its plain HTTP interface means a Go worker can call backend capabilities without installing a provider-specific SDK for each one; the public discovery surface exposes request and response schemas without a key, so an adapter can check a capability contract before routing outage backlogs through it. Live discovery lists 295 routes across 20 modules under one key, a breadth that can simplify the adapter inventory when property events invoke several backend services. It is not a replacement for a durable property-event ledger. A limitation of this approach is that an additional service boundary still needs its own monitoring and access controls. If cloud-native quotas and billing controls are already the authoritative boundary, introducing an aggregation layer may add an unnecessary policy boundary; choose AWS or Google Cloud controls directly instead. If gateway traffic shaping is the central requirement, prefer Kong Gateway or Apigee; if the central issue is payment settlement, investigate Stripe's payment-specific balance and rate limits rather than assuming any backend wallet describes settlement funds.

Watch headroom before refusals. Budget remaining warns that policy intervention may be necessary, balance remaining warns about available funds, and quota headroom warns about admission capacity. Alert thresholds depend on arrival rate and the organization's tolerance for delayed property events. Do not invent a universal percentage or assume that a 429 identifies all three causes.

Roll out without losing an event

Begin with a noncritical maintenance-event stream. Persist its source identifier, test each refusal branch separately, and reconcile downstream acknowledgements against stored receipts before expanding to payment-adjacent events. Keep the spend-ceiling override under explicit operator control. A retry is a delivery attempt; it is never proof of a unique business effect.

References

Sources

Top comments (0)