Platform
Resources
Best practices for feature flags in serverless environments like AWS Lambda
The transient nature of serverless architectures can make feature flag implementation challenging.
Feature flags empower developers to flexibly control serverless code without full redeployment, but they can also negatively impact cold starts and microservice dependencies. In this post, we’ll walk through key considerations and best practices for enabling feature flags in serverless platforms like AWS Lambda, Google Cloud Functions, and Cloudflare Workers:
Common challenges with feature flags in serverless situations
Three solutions for feature flags in serverless environments
Solution #1: Use centralized feature flags with Statsig
Solution #2: Create a custom flagging solution with external data stores like Cloudflare Workers KV
Solution #3: Integrate an external data store like Cloudflare Workers KV with Statsig
What are the challenges of using feature flags in serverless situations?
Cold starts and latency. Developing in serverless environments requires minimizing the impact of cold starts, but feature flagging often require adding SDKs that inherently add to initialization time. On each spin-up, fetching configuration data like flag states will require additional network calls. These can increase latency and negatively impact user experiences.
Inconsistent flag states. Serverless architectures usually involve large webs of complex and interdependent microservices. It’s common to have dozens (or even hundreds) of functions where flags are fetched, checked, and synced at unpredictable times. Ensuring accurate and consistent flag definitions can be tricky, especially with conditional dependencies, and lead to unpredictable or inconsistent results.
Tech debt and bloat. Serverless system designs encourage developers to break applications down into smaller, independent pieces, which can eventually result in overwhelming tech debt and bloat. Each new microservice might introduce or consume multiple flags and complicate maintenance tasks like flag deprecation and debugging.
Three solutions for using feature flags in serverless situations
Solution #1: Use centralized feature flags with Statsig
Statsig offers centralized feature flagging (Feature Gates) to define, check, and maintain consistent flags, even in highly distributed environments. Statsig also offers built-in tools for flag lifecycle management that make it easy for cross-functional teams to manage feature rollouts and product experiments at scale.
Ideally, your flagging SDK gets initialized outside of your serverless functions to minimize impact on cold start, like so:
That being said, we recognize this isn't always possible; some scenarios require initialization inside serverless functions and will look something more like this:
If this is your use case, even though Statsig server SDKs are designed for performance, it's still important to consider network impacts. Consider implementing warming tasks to promote function recycling or using Lambda layers for shared dependencies to further reduce latency.
If your system gets unusually sudden traffic spikes or is highly sensitive to frequent spin-ups, consider a custom setup with an external database below or schedule a call so we can help you build out your solution.
Solution #2: Create a custom flagging solution with external data stores like Cloudflare Workers KV
If your application is highly sensitive to cold starts and you’re not able to reference flags from a server, you might consider using an external persistent store like Cloudflare Workers KV or AWS DynamoDB to store flag definitions instead. In this architecture, your serverless functions can independently check flags from an external, low-latency database:
While this may address your latency issues by removing the need for SDK initialization in each serverless function, it does come with many implications that go against best practices. Maintaining a database for feature flags can introduce serious security risks like data corruption threats with no way to rollback. Furthermore, if your database isn’t designed for flagging, you will also need custom or manual processes for flushing, syncing, and polling to ensure consistent feature gating. A successful setup with this approach without a centralized flagging solution will require extensive documentation, maintenance, and caution.
Solution #3: Integrate an external data store like Cloudflare Workers KV with a centralized flagging platform like Statsig
If you need to balance performance with maintainability, consider an integrated solution that combines an external data store with a centralized flagging tool. Statsig offers out-of-the-box integrations with global persistent stores like Cloudflare Workers KV, Fastly, and Akamai Edge KV suitable for your needs.
In these setups, when you initialize the Statsig server SDK in your serverless environment, they are configured to perform frequent tasks (e.g., checks) with the external data store instead of directly calling the server with your flag definitions each time. Meanwhile, expensive tasks like syncs and polls are done directly between the database and your flag server with a data adapteroutside of the serverless functions:
Moving these costly network calls out of band (or out of the critical path of your edge function) improves performance while maintaining fast updates for flag roll outs and roll backs—without sacrificing consistency or maintainability.
Summary
| Pros | Cons | |
|---|---|---|
| Solution #1: Use a centralized flagging platform like Statsig |
+ Maintain consistent flags across complex architectures + Comes with debugging and lifecycle management |
- Not always performant, depending on use case |
| Solution #2: Create a custom flagging solution with external data stores like Cloudflare Workers KV | + Performant and potentially lower cost |
- Prone to inconsistent flag states - Introduces anti-patterns and security risks - Difficult to maintain |
| Solution #3: Integrate an external data store like Cloudflare Workers KV with Statsig |
+ Maintain consistent flags across complex architectures + Addresses performance issues with cold starts + Comes with debugging and lifecycle management + Readily available integrations |
- Higher budget (two integrated solutions) |
By incorporating one of these best practices depending on your use case, you can use feature flags in your serverless strategy to maintain agility while keeping your rollouts safe—even in a distributed environment with hundreds of microservices and functions.
Interested in Statsig for your serverless feature flagging needs? Sign up for free or book a live demo with us today.
Further reading:
Request a demo
