Aperture is an Apache-2.0 licensed, Go-based distributed load management platform, documented as FluxNinja Aperture, that gives cloud application teams rate limiting, caching, and request prioritization through SDKs and a global control plane.

What it is

Aperture is a distributed load management platform designed for rate limiting, caching, and prioritizing requests in cloud applications. It is built on a foundation of distributed counters, observability, and a global control plane, and it provides a suite of load management capabilities intended to improve the reliability and performance of cloud applications while optimizing cost and resource utilization. The project is written in Go and published under the Apache-2.0 licence, and it sits in the Infrastructure & Operations / Orchestration & Scheduling category, with topics covering caching, cloud-native, concurrency limiting, Kubernetes, LLM workloads, microservices, observability, rate limiting, and scheduling.

The concrete problem is that request control usually ends up implemented inside each service. Aperture moves that logic into shared policies instead. Rather than every microservice carrying its own limiter and result cache, an application defines labels for users, entities, or features, wraps the workload with startFlow and endFlow calls, and declares rate, concurrency, and priority behaviour in policy YAML. It also integrates with existing control points such as API gateways, service meshes, and application middlewares, so enforcement does not depend on SDK adoption alone.

Key capabilities

• Global rate and concurrency limiting through a distributed rate limiter, configured with bucket_capacity, fill_amount, and limit_by_label_key to control burst capacity and fill rate per label such as user.
• Fine-grained labelling for policy targeting, including user, tier, tokens, priority, and workload, so individual users can be limited separately and different tiers such as premium can receive different limits.
• Request prioritization and throttling when peak load exceeds external quotas or infrastructure capacity, driven by a priority label set to HIGH.
• Distributed result caching through the SDK, using resultCacheKey for lookup, flow.resultCache() to return a cached result, and flow.setResultCache() with a TTL expressed in seconds and nanos.
• Workload control points via startFlow and endFlow, with flow.shouldRun() deciding whether the workload executes.
• Declarative policies expressed as YAML blueprints, for example blueprint rate-limiting/base fetched from github.com/fluxninja/aperture/blueprints@latest, with policy_name, rate_limiter parameters, selectors, and label_matcher rules.
• Observability over workload metrics that can be sliced and diced by any defined label.

Who uses it and how

• Cloud-native teams running microservices on Kubernetes, where the topics list Kubernetes and cloud-native as first-class concerns.
• Teams serving LLM workloads, where the tokens label is explicitly described as capturing LLM AI tokens in a prompt, request complexity, or number of sub-actions.
• SaaS platforms with tiered customer bases, using the tier label to give premium users different limits from other users.
• Platform and site reliability groups that need per-user, per-feature, or per-endpoint control points alongside label-sliced performance metrics.
• Organizations already running API gateways or service meshes, which can act as control points instead of requiring every workload to be rewritten.

Getting started

The README documents a three-step SDK integration: define labels, wrap the workload with startFlow and endFlow, then configure and monitor policies through YAML blueprints. Project documentation lives at https://docs.fluxninja.com.

How it compares

The provided facts name no competing or comparable tool and no list of paid products that Aperture replaces, so this entry stands alone in this registry. The README positions Aperture alongside API gateways and service meshes as control points it integrates with, rather than as a replacement for them.

When to use it — and when not to

A self-hoster takes on a distributed system: distributed counters, a global control plane, and the observability that sits with them, so the operational cost is real and the payoff depends on having several services that need shared limits. A single small service with one process boundary would likely be better served by an in-process limiter, because the value of Aperture comes from coordination across workloads. The registry data also shows 99 open issues against 36 forks and 733 stars, and the README excerpt is image-heavy with its capability list truncated, so the excerpt alone is a thin basis for judging the full feature set.

// Tailor policies to get deeper insights into your workload with labels that
// capture business context.
const labels = {
  // You can rate limit each user individually.
  user: "jack",
  // And have different rate limits for different tiers of users.
  tier: "premium",
  // You can also provide the tokens for each request.
  // Tokens are flexible: LLM AI tokens in a prompt, complexity of a request,
  // number of sub-actions, etc.
  tokens: "200",
  // When peak load exceeds external quotas or infrastructure capacity,
  // requests can be throttled and prioritized.
  priority: HIGH,
  // Get deep insights into your workload. You can slice and dice performance
  // metrics by any label.
  workload: "/chat",
};

// Wrap your workload with startFlow and endFlow calls, passing in the
// labels you defined earlier.
const flow = await apertureClient.startFlow("your_workload", {
  labels: labels,
  // Lookup result cache key to retrieve a cached result.
  resultCacheKey: queryParams,
});

// If rate or quota limit is not exceeded, the workload is executed.
if (flow.shouldRun()) {
  // Return a cached result or execute the workload.
  const cachedResult = flow.resultCache();
  const result = await yourWorkload(cachedResult);
  flow.setResultCache({
    value: result,
    ttl: { seconds: 86400, nanos: 0 },
  });
}
//

blueprint: rate-limiting/base
uri: github.com/fluxninja/aperture/blueprints@latest
policy:
  policy_name: rate_limit
  rate_limiter:
    bucket_capacity: 60
    fill_amount: 60
    parameters:
      interval: 3600s
      limit_by_label_key: user
    selectors:
      - control_point: your_workload
        label_matcher:
          match_list:
            - key: tier
              operator: In
              values:
                - premium