Edge Event API Beta: Lower latency from everywhere

At the core of Inngest are events. Events are used to trigger, cancel, and continue functions.

Over the last couple of years, Inngest has become fundamental to more and more applications.

Developers deploy applications that run in cloud regions across the globe and many choose to run on distributed compute like Vercel Edge or Cloudflare Workers.

Up until now, Inngest core services, including the Event API, are run within cloud regions in the US. Unfortunately this leads to higher latency for those not running close to our own servers. We know that when you are sending an event within the critical path of your application, an API request for example, it has to be as fast as possible.

That’s why, today we are announcing our new Edge Event API as a closed beta.

Moving to the edge

For the Event API to have low latency from across the world, it needs to run close to your own servers. This means regional replication, caching, and validation of event payloads. The goal of our Event API v2 is to reach sub 100ms response times throughout the world.

We’re still testing the new API internally before rolling it out to the first wave of customers. We’re already seeing major improvements of anywhere between a 46-85% reduction in response times resulting in trimming response times by hundreds of milliseconds in some regions.

The Inngest architecture combines event streams, queues and durable execution into a single reliability layer. As all events begin their journey from the Event API directly to our event streams, it’s a primary segment to optimize performance.

API Requirements

While we are still testing different hosting solutions, generally, the new Event API has the following requirements:

• Event Keys must be replicated at all locations. We’ll start with caching, but with just caching, the first request may be slow to fetch the key from our database in the US. To get around this, we’ll push key changes to the API whenever any changes are made which also should alleviate issues with cache invalidation. This will include allow/deny lists for event names and IP addresses.
• Essential payload validation. Events that do not follow the required payload should be rejected as fast as possible
• Non-blocking event stream publishing. The requester should not be required to wait for the server to publish to the Inngest event stream. Publishing should happen asynchronously with failover.
• Payload size limit expansion. We currently limit the size of payloads to 4MB, but customers often request larger sizes, especially when sending events in bulk. While the new API will have limits to start, it will be designed for larger payload sizes.

These are the essential requirements in addition to the features already built into our v1 Event API. Each one of these is intended to improve performance or lay the foundation for new features and improved capacity.

How to join the beta

You can be first in line to try the new Event API by upvoting the project directly on our roadmap with your Inngest account email. Please share any context on your application that you’d like to start using it for. Additionally, if you just want to be notified when the feature comes out of beta for wide usage, add your email here.

We’re planning to roll this out first for sending events via our SDKs or HTTP. Due to the requirements for transforms, webhooks will not be part of this beta, but more webhook features will be coming later this year!

Onward

We’re committed to reducing latency across the board and our new Event API is only part of the picture. We’ve been steadily shipping improvements to function execution to reduce latency and we have several additional projects planned in our immediate roadmap.

Latency is extremely important and will be essential for future features like RPC-style direct function invocation from your APIs. We’d love to hear your feedback on this and we’re excited to begin beta rollout very soon!