Inngest vs AWS Step Functions for multi-tenant rate limiting and concurrency keys—who does it better?

Most teams don’t feel the pain of multi-tenant rate limiting and concurrency keys until it’s too late—when one noisy customer or a burst of traffic quietly starves everyone else. At that point, the question becomes practical, not theoretical: should you lean on AWS Step Functions, or reach for something like Inngest that bakes multi-tenant flow control into the core model?

Quick Answer: The best overall choice for multi-tenant rate limiting and concurrency control is Inngest. If your priority is deep integration with the broader AWS ecosystem and you’re okay building a lot of scaffolding yourself, AWS Step Functions can work. For teams already heavily invested in Lambda + Step Functions but needing more structured flow control, a hybrid approach (Step Functions + custom throttling layer) is often a pragmatic middle ground.

---

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Inngest	Teams that need native multi-tenant concurrency keys, rate limiting, and observability without rebuilding queues	Code-level durability with built-in flow control and Traces	Requires adopting Inngest SDKs and platform alongside your existing stack
2	AWS Step Functions	AWS-first teams needing visual workflow orchestration across many AWS services	Tight integration with AWS ecosystem and managed state machine execution	No first-class multi-tenant concurrency keys; requires extra services for rate limiting and noisy-neighbor control
3	Hybrid: Step Functions + Custom Throttling Layer	Existing Step Functions users who can’t migrate yet but need better tenant isolation	Lets you keep current workflows while adding some concurrency/rate limits	You’re back to building/maintaining infra: queues, DLQs, custom metrics, and control-plane logic

---

Comparison Criteria

We evaluated Inngest vs AWS Step Functions for multi-tenant rate limiting and concurrency keys using three practical criteria:

• Multi-tenant flow control primitives:
  How directly can you express “don’t let tenant A starve tenant B,” “cap this customer at N concurrent runs,” or “enforce provider API quotas per tenant” in the tool itself—without rolling your own queue stack?

• Code-level durability and recovery:
  Can you model work as named, durable steps with automatic retries, idempotency, and checkpointing so that runs resume from the last successful step instead of starting over—and can you recover in bulk without writing admin tools?

• Operational visibility and control plane:
  When things break, can you see step inputs/outputs per tenant, understand why you’re throttling, and then query, cancel, or replay specific runs or tenant segments—without log-grepping across systems?

From a former “maintain-the-queue-stack” engineer’s point of view, those three criteria are what determine whether a concurrency solution actually works in production.

---

Detailed Breakdown

1. Inngest (Best overall for native multi-tenant concurrency and rate limiting)

Inngest ranks as the top choice because multi-tenant flow control—concurrency keys, rate limits, prioritization—is a first-class feature, not an afterthought you bolt on with more AWS services.

Under the hood, every step.run() is a durable, retriable unit of work with built-in checkpointing. Flow control then wraps around those steps so you can say, “treat all work for tenant-123 as a single lane with its own concurrency and rate limits,” without building your own workers and queues.

What it does well

• Built-in concurrency keys and multi-tenant queues

  Inngest gives you concurrency keys and flow control as native concepts. Customers like GitBook and Otto use this to effectively get virtual queues per tenant:

  • GitBook uses multi-tenant queueing and concurrency so each GitBook space has its own lane—no one repo or space starves the others.
  • Otto uses concurrency keys for multi-tenant flow control so they can rate-limit user actions across queues while still prioritizing important workloads.

  The net effect: you can express patterns like:

  • “Max 3 concurrent workflows per tenant.”
  • “Global cap of 100 executions per second, but no more than 2 per space.”
  • “Pause or slow down a specific tenant without touching everyone else.”

  And you do it at the Inngest layer, not by wiring SQS → Lambda → DynamoDB just to simulate “per-tenant queueing.”

• Code-level durability: steps, retries, and checkpointing

  Every unit of work is written as business logic with durable steps:

  import { inngest } from "./client";
  
  export const processTenantEvent = inngest.createFunction(
    { id: "process-tenant-event" },
    { event: "tenant/event" },
    async ({ event, step }) => {
      const tenantId = event.data.tenantId;
  
      // This step is durable, retriable, and checkpointed
      await step.run("process", async () => {
        // do the work for this tenant
      });
    }
  );
  

  The mechanism:

  • step.run() wraps each step as a “code-level transaction.”
  • On failure, Inngest retries automatically; on success, it records a checkpoint.
  • On subsequent retry, the function resumes from the last successful step instead of starting from scratch.

  The outcome: retries and partial failures no longer create ambiguous state per tenant—you get deterministic, step-wise execution with clear visibility.

• Flow control + observability in one place

  Rate limiting isn’t useful if you can’t see why you’re hitting it or what it’s doing to tenants. Inngest couples flow control with instant Traces:

  • Real-time traces per run, including step-level inputs/outputs.
  • Structured logs, including “every prompt / response pair” for AI workloads.
  • Query, cancel, or replay runs directly from the UI.

  For multi-tenant systems, that means you can:

  • Filter by tenant, see all their runs and where they’re queued or throttled.
  • Replay a subset of runs (e.g., “all failures for tenant X in the last hour”) without building internal admin tools.
  • Confirm that concurrency keys are doing what you expect during an incident.

Tradeoffs & Limitations

• Adoption cost if you’re deep in AWS-only land

  Inngest is agnostic about where your code runs—edge, serverless, traditional—but it is a distinct platform. That means:

  • You’ll adopt Inngest SDKs (TypeScript, Python, Go) and the Inngest Cloud control plane.
  • You keep your existing infrastructure, but move workflow durability and flow control into Inngest.

  For pure-AWS shops that have heavily invested in Step Functions definitions, this can be a shift in mental model. The tradeoff is offloading orchestration, retries, DLQ logic, and concurrency control into something purpose-built for it.

Decision Trigger

Choose Inngest if you want multi-tenant concurrency and rate limiting to be expressed in code rather than in infrastructure. If your top priorities are:

• Tenant isolation and fairness (noisy-neighbor protection).
• Built-in concurrency keys and rate limits with minimal config.
• Clear Traces plus Replay so you can recover from failures without building tooling.

…Inngest is the better fit.

---

2. AWS Step Functions (Best for AWS-heavy stacks that accept DIY flow control)

AWS Step Functions is the strongest fit when you’re deeply tied into AWS and need visual workflows across many AWS services, and you’re okay treating multi-tenant concurrency and rate limiting as a DIY project.

Step Functions is a managed state machine service. It coordinates tasks (typically Lambdas or service integrations) and manages transitions, retries, and error handling according to a JSON/YAML-defined state machine.

What it does well

• Tight orchestration with AWS services

  Step Functions shine when you:

  • Orchestrate S3 → Lambda → DynamoDB → SNS flows.
  • Need service integrations with things like ECS, Glue, or SageMaker.
  • Want a visual graph of your state machine and basic execution history in the AWS Console.

  If your entire world is AWS, the native integration is hard to beat.

• Stateful execution and per-step retries

  Step Functions provide:

  • Built-in retries with backoff and catch handlers.
  • State passing between tasks.
  • Execution history per run.

  As an orchestrator, it’s solid—particularly for single-tenant or “doesn’t need careful per-tenant control” workflows.

Tradeoffs & Limitations

• No first-class multi-tenant concurrency keys

  There is no notion of a “concurrency key” or “per-tenant queue” in Step Functions itself. To get multi-tenant rate limiting and concurrency, you typically end up combining:

  • Lambda concurrency limits (global or per-function).
  • API Gateway throttling and usage plans.
  • SQS or Dynamo-based queues plus token buckets.
  • Custom metadata tables to track per-tenant counts and last-run timestamps.

  The outcome is a patchwork control plane:

  • You model concurrency rules in DynamoDB or Redis.
  • You use middleware Lambdas to check and enforce quotas.
  • You write glue code to update metrics and handle delayed retries.

  None of that is truly multi-tenant aware in the way concurrency keys are. It’s possible, but you’re effectively building the flow-control layer yourself.

• Limited, fragmented observability for tenant flows

  Step Functions’ execution history is helpful but:

  • Doesn’t natively understand “tenant” as a first-class dimension.
  • Often requires CloudWatch Logs + X-Ray + custom correlation IDs to trace a tenant’s behavior end-to-end.
  • Makes it painful to answer questions like “show me all executions throttled for tenant X in the last hour.”

  Recovery is also DIY:

  • No native “replay this failed step with the same inputs” at scale.
  • You end up writing scripts or internal UIs to requeue or re-run failed executions.

• Cross-service complexity is your problem

  With Step Functions, you’re responsible for wiring all the parts:

  • Workers (Lambdas, containers).
  • Queues (SQS, Kinesis, or custom stores).
  • Idempotency and retries beyond what Step Functions model.
  • Dead-letter queues and recovery tooling.

  This is exactly the infrastructure tax I spent years maintaining—workers, retries, idempotency keys, rate limits, DLQ recovery—and what Inngest is designed to replace.

Decision Trigger

Choose AWS Step Functions if:

• Your workflows are deeply coupled to AWS services.
• You already have (or are willing to build) a custom layer for multi-tenant rate limiting and concurrency.
• You value visual state machine editing and AWS-native integrations over out-of-the-box flow control and replay.

If you’re okay being the team that maintains the queue stack and control plane for multi-tenant throttling, Step Functions can be “good enough.”

---

3. Hybrid: Step Functions + Custom Throttling Layer (Best for “we can’t move yet” teams)

A hybrid approach stands out when migrating off Step Functions isn’t realistic in the short term, but you can’t ignore noisy neighbors and API quotas anymore. Here, you keep Step Functions as the orchestrator while adding your own rate-limiting and concurrency keys in a separate control plane.

What it does well

• Gradual path from “bare Step Functions” to managed flow control

  You can:

  • Keep existing state machines unchanged.
  • Insert a throttling layer that sits in front of critical steps or triggers.
  • Centralize rate limiting logic in a custom service (often built with DynamoDB + Lambda or Redis + ECS).

  This gives you incremental wins—per-tenant limits, some fairness—without a full replatform. For many teams, that’s politically easier than a full migration.

• Targeted control over your highest-risk flows

  You can focus the hybrid approach on:

  • High-volume, noisy tenants.
  • Expensive external APIs (LLMs, payment gateways, CRMs).
  • Critical multi-step syncs where noisy neighbors cause real damage.

  That reduces risk while buying time to decide whether to eventually move orchestration to something like Inngest.

Tradeoffs & Limitations

• You’re now in the business of building a flow-control platform

  Even in a hybrid setup, you’re taking on:

  • A service to track tokens/quotas per tenant.
  • Mutex-like semantics for per-tenant concurrency.
  • Custom dashboards and metrics for this layer.
  • Incident playbooks around this new service.

  You’ve basically split responsibility: Step Functions for orchestration, your service for concurrency and rate limiting. That’s a lot of mental and operational overhead.

• Fragmented debugging and replay

  When something breaks, you now look at:

  • Step Functions execution history.
  • Logs and state in the throttling layer.
  • Underlying Lambda/worker logs.

  Replay is especially painful:

  • You might need to “un-throttle” specific tenants.
  • Manually re-drive traffic through Step Functions.
  • Ensure idempotency across multiple layers.

  You’re getting some benefits of concurrency control, but none of the unified Traces and Replay that platforms like Inngest provide out of the box.

Decision Trigger

Choose a hybrid approach if:

• You’re locked into Step Functions in the short term (compliance, org constraints, heavy investment).
• Multi-tenant failures are hurting you today and can’t wait.
• You’re willing to own a custom flow-control service as a bridge solution.

Think of this as a stopgap; it addresses symptoms, but you’re still running your own control plane.

---

Final Verdict

If your question is specifically about multi-tenant rate limiting and concurrency keys, not just “generic workflow orchestration,” the comparison isn’t close:

• Inngest makes multi-tenant flow control a core primitive:

  • Concurrency keys and virtual queues per tenant.
  • Code-level durability via step.run(), automatic retries, and checkpointing.
  • Instant Traces, structured logs, and Replay/Bulk Cancellation so you can query, cancel, or replay tenant runs without writing admin tooling.
  • Used in production by teams like GitBook and Otto expressly for multi-tenant concurrency guarantees.

• AWS Step Functions is a strong orchestrator in the AWS ecosystem, but:

  • Has no first-class concept of per-tenant concurrency keys.
  • Requires a separate layer (Lambda, DynamoDB, SQS, etc.) to implement rate limiting and noisy-neighbor protection.
  • Spreads observability across multiple services, forcing teams back into the pattern of building their own operational UI and recovery tooling.

If you’re tired of paying the infrastructure tax—wrangling workers, queues, rate-limiters, and DLQs just to keep tenants from stepping on each other—Inngest does multi-tenant rate limiting and concurrency better because it puts durability and flow control in your code, not in a pile of services you have to stitch together.

---

Next Step

Get Started