Airlock is a lightweight gateway for multi-service entry points. It carries no business logic. Its job is to decide whether a request should enter, where it should go, and how the journey should be observed.
The motivation was straightforward: once a system has more than a couple of services, authentication, rate limiting, timeouts, retries, and request logs start to repeat in every service. Rather than letting each team maintain its own copy of those policies, Airlock pulls the boundary concerns into one layer.
The request path
Every request follows a fixed sequence:
- the listener accepts the connection and parses the protocol and basic metadata;
- the router selects an upstream from host, path, and headers;
- the middleware chain handles request IDs, identity, rate limits, timeout budgets, and retry policy;
- the upstream selector reads health state and picks an available instance;
- the response records status, latency, and upstream metadata.
Routes and middleware are described by configuration rather than hard-coded. Adding an upstream should mean changing configuration, not relearning the whole entrance.
Boundaries and trade-offs
The easiest way for a gateway to go wrong is to slowly become a second business system. Airlock deliberately avoids business orchestration, database access, and domain rules.
It does a small set of things:
- authenticate and forward identity;
- rate-limit by route and tenant;
- give every route its own timeout budget;
- retry only idempotent requests, within a limit;
- fail fast and break the circuit when an upstream misbehaves.
Retries happen only when a request is explicitly retryable. Otherwise the gateway turns one failure into several writes.
Observability
Every request carries a request ID from the entrance and keeps it through logs, metrics, and traces. Beyond QPS and error rate, Airlock records upstream latency, rate-limit hits, retry counts, and circuit state separately.
Health checks are not just "is the port open". They look at recent error rate and latency. An upstream that accepts connections but consistently times out should stop receiving new requests.
Current state
The routing core, middleware chain, and hot config reload are in progress. Rate limiting starts with in-process counters before moving to Redis for multi-instance coordination. Next come the admin API, canary routing, and load-test scripts.
A good gateway should be invisible when healthy. When it fails, it must explain why.