From a Sanity edit
to a live page.

Some Sanity documents contain a lot of rich text, and that can make an event too big to publish, especially when it carries every language version. Trying to publish it would simply fail. So the gateway checks the size first. If a payload would be too big, it uploads the whole thing to S3 (AWS's file storage) and publishes events that carry the file's location instead of the content. Consumers download the file from S3 and ingest it much as they would an ordinary event.

It's one extra moving part, added so that large documents still make it through.

Watch a too-big event take the S3 route

First, what would happen if the gateway just tried to publish a big document. Then what it actually does.

We added this route after an event hit the size limit in production. I didn't expect to hit it and didn't know about it until it happened. The events were large mostly because they carried content for every locale, meaning every language version of a document. Most events are well under the limit, but the ones with the most content are the ones that matter most.

AWS has since raised its limit for events, messages and asynchronous Lambda invocations from 256 KB to 1 MB, as described in an AWS Compute Blog post from January 2026. Some events still need the S3 route today, even with the higher limit.

The 9-second wait comes from how many backends read the same stream. More than 50 BFFs (the small backends, one per part of the website) read from one Kinesis stream, and by default they all share the same read capacity, so they end up waiting on each other. The improvement I'd make is to give each BFF its own dedicated way to read, which I expect would remove most of that wait. The BFFs on this stream don't use enhanced fan-out today. Each BFF has a listener Lambda with the stream as its event source (the setting that tells Lambda to run the code whenever new records arrive), a DynamoDB table to store what it reads, and a separate REST Lambda behind API Gateway that serves requests.

A best-case estimate of the saving. AWS documents a typical average delivery delay of about 70 milliseconds for a reader with its own dedicated connection, however many other readers there are. For comparison, it documents about 200 milliseconds with one shared reader and about 1,000 milliseconds with five. If the whole 9.4 second wait is the cost of sharing, and dedicated reading brought it down to about 70 milliseconds, that would save about 9.3 seconds and bring the roughly 13 second total to roughly 3.7 seconds. That's the best case, but the arithmetic above suggests sharing really is most of the wait.

How it would work. Kinesis splits a stream into shards, and every reader reads every shard, so adding shards alone doesn't give each BFF its own lane. The AWS option built for this is called enhanced fan-out. Each registered reader gets its own read capacity, and AWS pushes new records to it instead of the reader repeatedly asking for them. AWS limits how many readers can be registered this way: 20 per stream on standard streams, and 50 on streams in its on-demand Advantage mode. Because each BFF reads through a Lambda event source, AWS lets that event source be pointed at a dedicated reader, which is a configuration change rather than new application code. With more than 50 BFFs, that limit means not every BFF can have a dedicated reader on one stream. One way round it is to give dedicated readers only to the BFFs where freshness matters most. Another is to have EventBridge send events to a few streams instead of one, so fewer BFFs share each. Splitting the readers across three streams would cut the wait to about a third with no change to any BFF's code.

Why it wasn't done first. The extra setup and cost weren't judged worth it. Before this system, content was compiled once a night by a scheduled job, and it had badly stagnated as a result. Going from a day or more to about 13 seconds was already a huge improvement. Enhanced fan-out is billed per reader per shard-hour, plus for the data read.