DEV Community

BenedictVance6863
BenedictVance6863

Posted on

Structured JSON Logging for SaaS Pricing-Rule Rollbacks — A Safe Event Path

#logging #observability #python #saas

A logging service is safe enough for a pricing rollout when one request can be followed from flag decision to invoice effect, and when the same record can support an immediate rollback. My decision rule is simple: choose the smallest JSON API that preserves correlation, immutable decision evidence, and a bounded retention path. A pretty stream of messages is not enough.

Short answer: emit one structured event for the flag decision and one for the resulting pricing action, attach a request and rollout identifier to both, and make the logger fail open so billing never waits on observability. Keep the rollback signal independent from the pricing service.

What must a rollback log answer?

When a new pricing rule is behind a flag, the useful question is not "did the endpoint return 200?" It is: which rule was selected, for which account, under which rollout, and what happened before the flag was disabled? A log entry should make those answers queryable without parsing prose.

For a B2B SaaS application, I would record an account identifier, request identifier, rule version, flag state, evaluation reason, currency, and outcome. I would not put an email address, payment token, or full request body in the event. The logger receives a stable account key and a redacted result. That boundary matters because an operational shortcut can become a data-retention problem.

The event stream needs two timestamps: the producer's event time and the collector's receipt time. Clock skew is real, and receipt time is the better anchor when reconstructing an incident. OpenTelemetry describes logs as timestamped records with context that can be correlated with traces and other signals, which is the standard shape I want even when the transport is a small JSON endpoint.

A small Python path from decision to event

The example below keeps the application contract deliberately boring. The logging client has a timeout, sends JSON, and never turns a logging outage into a pricing outage. In production, the queue and transport can change; the event schema should not change casually.

from dataclasses import asdict, dataclass
from datetime import datetime, timezone
import json
from urllib.request import Request, urlopen


@dataclass(frozen=True)
class PricingEvent:
    event_name: str
    event_time: str
    request_id: str
    rollout_id: str
    account_id: str
    rule_version: str
    flag_enabled: bool
    decision_reason: str
    currency: str
    outcome: str


def emit_event(endpoint: str, event: PricingEvent) -> None:
    payload = json.dumps(asdict(event)).encode("utf-8")
    request = Request(
        endpoint,
        data=payload,
        headers={"Content-Type": "application/json"},
        method="POST",
    )
    try:
        with urlopen(request, timeout=0.25) as response:
            if response.status >= 300:
                raise RuntimeError(f"logging status: {response.status}")
    except Exception:
        # Pricing remains available; a local queue can retry the event.
        pass


def apply_price(
    endpoint: str,
    request_id: str,
    rollout_id: str,
    account_id: str,
    flag_enabled: bool,
    rule_version: str,
    currency: str,
) -> str:
    reason = "rollout_enabled" if flag_enabled else "rollback_default"
    outcome = "new_rule" if flag_enabled else "default_rule"
    emit_event(
        endpoint,
        PricingEvent(
            event_name="pricing.rule_selected",
            event_time=datetime.now(timezone.utc).isoformat(),
            request_id=request_id,
            rollout_id=rollout_id,
            account_id=account_id,
            rule_version=rule_version,
            flag_enabled=flag_enabled,
            decision_reason=reason,
            currency=currency,
            outcome=outcome,
        ),
    )
    return outcome
Enter fullscreen mode Exit fullscreen mode

The important behavior is the event, not the URL. rollout_id lets an operator compare the new rule with the default rule after a flag change. request_id connects a single checkout attempt to its application logs. The timeout is intentionally shorter than a normal customer request budget; the logging path must not become a hidden dependency of billing.

Where simple JSON APIs usually fail

The first trap is treating logs as a debug diary. A message such as used new price cannot distinguish a disabled flag from a missing configuration, a fallback, or an account that was excluded by policy. Enumerated fields make those paths visible. They also make evaluation easier: a test can assert that a rollback produces rollback_default, rather than searching for a phrase.

The second trap is retrying blindly. If the collector accepts an event and the client times out, a retry may create a duplicate. Give every event a deterministic identifier, or make the receiver deduplicate on request_id, event_name, and rule_version. At-least-once delivery is a reasonable default, but pretending it is exactly-once creates misleading incident counts.

The third trap is putting a full pricing payload into every record. That raises token and storage costs for downstream AI analysis, and it increases the amount of sensitive data that must be governed. I prefer a compact event plus a pointer to a separately controlled record when deeper inspection is justified. The compact record is what the eval harness consumes.

A hosted collector, a self-hosted collector, and a direct application database can all receive JSON. Their meaningful differences are operational. A hosted collector usually reduces maintenance but introduces a dependency and a data-boundary review. A self-hosted collector keeps routing and retention under team control but adds upgrades, capacity planning, and on-call work. A database table offers familiar queries, yet it can couple incident traffic to the primary application store.

The limitation is operational fit. A hosted collector is a poor choice when data must remain inside a tightly controlled boundary; a self-hosted collector is a poor choice when nobody owns upgrades and capacity. A direct application database is a poor choice when incident volume can compete with the primary store. Those are boundaries, not product rankings.

I would compare them with a short decision table rather than a feature checklist:

Decision test Acceptable evidence Reject when
Rollback reconstruction Query by rollout and request identifiers Events require free-text parsing
Failure isolation Timeout, local buffer, and retry policy Billing blocks on collector health
Data control Redaction and retention are explicit Raw customer payloads are default
Schema durability Versioned event fields and stable timestamps Producers silently change field meaning

No option wins by having the longest feature list. The right fit is the one whose failure mode the team can operate at 2 a.m.

How should a SaaS application choose a JSON logging service API?

Start with an eval fixture containing three accounts: one receiving the new rule, one excluded from the rollout, and one processed after rollback. Assert the selected rule, the reason, and the correlation fields. Then inject a slow collector and verify that the pricing request still completes within its normal budget. The 250 ms logging timeout is a useful test boundary, not a promise that every network is fast. Finally, send the same event twice and confirm the query used by the incident runbook does not count it twice.

That is the part I would refuse to hand-wave.

The rollout checklist belongs in the deployment review: define the event schema, redact before serialization, assign a rollout identifier, set a timeout, document retry and deduplication behavior, test the rollback path, and choose a retention period. After deployment, watch event delivery failures separately from pricing outcomes. A quiet logging stream can mean a healthy release, or it can mean the collector is unreachable.

Keep it boring.

The final decision is therefore architectural: use JSON logs as durable evidence of a pricing decision, keep their transport replaceable, and make rollback behavior observable without making observability part of the payment path. That gives the team a useful record when the flag changes and a contained failure when the record cannot be delivered.

References

Top comments (0)