backend / web frameworks / fastapi / 11_external_api_auth.md

How would you handle external API authorization, logging, and caching?

3 interview angles 1 min read source

How would you handle external API authorization, logging, and caching?

Answer

Authorization

  • Keep credentials out of code: use environment variables or a secret manager (e.g. AWS Secrets Manager, HashiCorp Vault).
  • For OAuth2/API keys: add tokens to outgoing requests in a single place (e.g. httpx client with auth= or a custom transport that injects headers).
  • Prefer short-lived tokens and refresh them in the client; cache the refreshed token until expiry.

Logging

  • Log at the client layer: request URL/method, response status, duration, and optionally a correlation ID. Avoid logging full bodies or secrets.
  • Use structured logging (JSON) and consistent levels (e.g. WARNING for 4xx/5xx, INFO for success, DEBUG for request/response only in dev).
  • Optionally integrate with tracing (OpenTelemetry) so external calls appear in the same trace as your API.

Caching

  • Use HTTP cache headers when the external API supports them: respect Cache-Control, ETag, Last-Modified and implement conditional requests.
  • For application-level caching: use a cache (e.g. Redis, in-memory) keyed by (method, URL, and optionally query/auth scope). Set TTL from Cache-Control or a default.
  • Invalidate or use short TTL for data that must be fresh; use longer TTL for stable reference data.

Interview angle

  • “How do you manage an OAuth token for an outbound API?” - fetch once, cache it with its expiry, and refresh proactively before it lapses. Guard the refresh with a lock so concurrent requests don’t all refresh simultaneously, which is the usual cause of rate-limit errors on the token endpoint.
  • “Where does the credential live?” - a secrets manager fetched at runtime, or workload identity where the platform issues a short-lived credential and there’s no stored secret at all. Never in the image or the repo. See ../../../system_design/04_secrets_config/01_secrets_and_configuration.md.
  • “How do you handle a 401 mid-flight?” - refresh once and retry the request a single time. Retrying repeatedly on 401 usually means the credential is genuinely wrong, and looping just triggers lockout.