Solana gRPC anti-patterns E1: serverless gRPC subscribers
TL;DR
- Serverless functions (like Lambda or GCF) let you run code without managing a server
- They need zero management, but run in an ephemeral, resource-constrained environment that shuts down every 15 minutes on Lambda (9–60 minutes on GCF) and has to be started up again
- Every cold start leaves you dependent on your cloud provider’s state and adds an extra 200 ms to 2+ seconds of delay on average
- On top of that, the function has to do a TCP and TLS handshake, HTTP/2 negotiation, and then the gRPC subscribe request, totalling 3-4 round trips each time
- Using Lambda (and similar tools) to subscribe to Solana events leads to dropped messages, latency spikes, and inconsistent performance
- It also causes you to miss transaction confirmations, because the overhead latency often takes longer than it does for the event to land in a block
- The fix is to use a VPS or bare metal server that keeps the connection open permanently, lets you configure it manually, and allows for much higher bandwidth
Introduction
We’ve been running infrastructure for the most demanding workloads on Solana since before its testnet. Over the past 6 years, we’ve spent almost every day optimising our code, breaking things and chewing glass (and we’ll continue to do so). But while we handle the heavy lifting, there are decisions on your end that can make or break the whole setup.
Along the way of powering both enterprises and startups, we’ve seen the same mistakes come up again and again. As our customers (that’s you!) are building the most ambitious things on the fastest L1, we want to be proactive and make sure the infrastructure side of things, even on your end, never gets in the way.
This article is the first in a series where we break down the most common Solana streaming anti-patterns, so you can avoid them early instead of fixing in prod.
First up is using Lambda and other serverless functions to subscribe to gRPC streams, resulting in constant data skips and missing transaction confirmations.
What is Lambda?
Lambda is Amazon’s serverless compute service. You upload a function, AWS runs it on demand, and you pay only for the milliseconds it runs. As it’s purpose-built for short-lived workloads, each execution window is capped at 15 minutes (default is 3s). If your function runs longer, AWS stops the process, and you have to start again from scratch in a new environment, with all the usual cold-start costs.
During execution, network throughput depends on the function's current load and the amount of memory you’ve allocated. Because you are typically sharing it with thousands of other tenants, you will see significant jitter and inconsistent performance.
Google Cloud Functions and Azure Functions work similarly and share similar constraints. For the rest of this article, we will use “Lambda” as shorthand for all of them, since it is the most popular option.
Serverless functions VS servers
A server, whether it’s a bare metal box or a VPS, is a machine you configure yourself. You choose the CPU, the RAM, the bandwidth, set up the OS, deploy your code, wire your process manager, and maintain it over time. Think of it like renting an office: you pick the building, set up the furniture, choose the internet plan, and stay for as long as you’re paying. Nobody else can use it while you’re away, and it’s at your disposal whenever you need it.
A serverless function is much easier to get started with. You write your application logic, hand it to the cloud provider, and they decide where and how to run it. That is more like joining a shared coworking space. You avoid the hassle and can just show up and work, but you have zero control over the environment. Desks might be full, your seat might be taken when you get back from lunch, and you can’t rearrange the furniture or stay past closing hours.
For bursty, stateless workloads such as REST APIs, image processing, or scheduled tasks, this trade-off is perfect. You handle a request, return a response, and you’re done. For a gRPC stream that needs to stay open for hours, days, or indefinitely, it’s a killer.
What is the problem?
One of the biggest benefits of gRPC streaming over polling is avoiding the constant request-response trips. You establish a subscription once and get a low-latency, continuous data firehose. Setting that up isn’t free, though. Every new connection has to complete a multi-step handshake before sending any data:
- Opening the TCP connection (one network RT)
- Setting up encryption (one RT with TLS 1.3, two with TLS 1.2)
- Exchanging HTTP/2 settings for gRPC (another RT)
- Sending the gRPC subscribe request with the program, accounts, and commitment you want to receive (final RT)
That is 3-4 network RTs before a single update arrives (happening every 15 minutes). And every time, while you are reconnecting and resubscribing, the chain keeps moving. Any block produced or transaction included in that gap is data you’ll never see.
On top of that, Lambda has to provision the execution environment before the handshake even starts. AWS needs to allocate the runtime, initialise your code, and set up networking. This is the cold start, and it adds an overhead delay on top of the handshake (on average, 500 ms-2s).
If you send a transaction and only then spin up a Lambda to listen for its confirmation, you are looking at 600 ms to 2.2+ seconds just to get your listener online. By that point, the transaction is usually already in a block, and you have missed it.
This is not a one-time problem either. Lambda’s 15-minute cap means the platform kills your subscription every quarter hour, and retrying just reruns the same slow sequence, without fixing data gaps.
The fix: stay online
If you are going to build on the fastest chain out there, your infrastructure has to keep up. Get a server (VPS or bare metal), keep your connection open, and make sure you have enough network capacity for heavy streams.
It’s more hands-on than a serverless function, but for most Solana builders, it’s the right choice and saves you a lot of headache in the long run.