Observability & Evolution

Request tracing

Observability model

Observability is built in. Evolution is additive.

• Every request is tagged with a unique identifier.

• The identifier is propagated across the gateway and services.

• Logs and errors include the identifier for correlation.

Logging

• Structured logs capture request metadata and timing.

• Errors include context without leaking internals.

• Sensitive values should be redacted at the edge.

Compatibility rules (practical)

• New endpoints ship under versioned namespaces.

• Existing response shapes remain stable.

• Internal refactors do not change public contracts.

Acceso evolves through additive changes rather than breaking updates:

Evolution strategy

• latency (p50/p95/p99)

• throughput (RPS)

• error rate (by error code)

• cache hit rate (for hot paths)

• upstream health and saturation signals

Service-level metrics typically include:

Metrics

• Prefer adding fields over changing fields.

• Prefer new endpoints over changing semantics in-place.

• Keep errors structured and stable for client automation.