Add adaptive concurrency blog post

[welteki]

Description

Add a new blog post introducing adaptive concurrency for the OpenFaaS queue-worker. Compares greedy vs adaptive dispatch, covers known concurrency limits (max_inflight) and variable upstream capacity use-cases. Includes an SVG diagram, side-by-side comparison chart, and Grafana dashboard screenshots.

Motivation and Context

Adaptive concurrency is a new feature in the JetStream queue-worker that prevents overloading functions by learning their capacity and throttling dispatch to match. This post explains the problem it solves, how it works, and shows real benchmark results.

Have you applied the editorial and style guide to your post?

Yes

How have you tested the instructions for any tutorial steps?

Types of changes

• New blog post
• Updating an existing blog post
• Updating part of an existing page
• Adding a new page

Checklist:

• I have given attribution for any images I have used and have permission to use them under Copyright law
• My code follows the writing-style of the publication and I have checked this
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s

[reviewfn]

AI Pull Request Overview

Summary

• Adds a new blog post introducing adaptive concurrency for OpenFaaS queue-worker.
• Includes SVG diagram and PNG screenshots from Grafana.
• Explains greedy vs adaptive dispatch, concurrency limits, and upstream capacity use-cases.
• Provides examples, benchmarks, and configuration instructions.

Approval rating (1-10)

8 - Well-structured blog post with clear explanations and examples, but could benefit from more technical depth on algorithm implementation.

Summary per file

Summary per file

File path	Summary
_posts/2026-03-13-adaptive-concurrency.md	New blog post on adaptive concurrency feature
images/2026-03-adaptive-concurrency/grafana-load-replicas-and-status.png	Grafana dashboard screenshot showing load metrics
images/2026-03-adaptive-concurrency/grafana-queue-depth-and-inflight.png	Grafana chart of queue depth and inflight requests
images/2026-03-adaptive-concurrency/greedy-vs-adaptive-diagram.svg	SVG diagram comparing dispatch methods
images/2026-03-adaptive-concurrency/greedy-vs-adaptive.png	Side-by-side comparison chart

Do not include node_modules or vendor directories.

Overall Assessment

The blog post effectively communicates the adaptive concurrency feature, providing practical examples and benchmarks. However, it lacks depth in implementation details and potential edge cases.

Detailed Review

Detailed Review

Technical Accuracy and Depth

• The explanation of greedy vs adaptive dispatch is clear, but the algorithm description (lines 54-60) is high-level. Consider adding more specifics on the feedback mechanisms, such as exact back-off multipliers or how "sustained period" is defined, to help developers understand tuning options.
• The claim of "~50% faster completion time" (line 72) should reference the specific benchmark conditions or provide error margins. Without data reproducibility details, this could mislead users expecting similar improvements.
• For functions with variable upstream capacity, the reliance on 429 responses (line 108) assumes functions are correctly implemented to return this status. This could fail silently if functions don't signal back-pressure properly, leading to undetected overload.

Content Structure and Clarity

• The post is well-organized with headings and examples, but the "Try it out" section (line 112) assumes users have specific tools (hey, faas-cli) installed. Add prerequisites or alternative commands for broader accessibility.
• Image captions (lines 136-141) are descriptive, but ensure alt text in HTML for accessibility if the site supports it.
• The further reading links are relevant, but verify all URLs are correct and point to existing documentation to avoid broken links.

Potential Risks and Assumptions

• Enabling by default (line 114) could impact existing deployments if users rely on greedy behavior for certain workloads. Highlight migration considerations or how to disable it.
• The algorithm's adaptation to replica changes (line 60) might not handle sudden scale-downs efficiently, potentially causing temporary queue buildup. Clarify recovery behavior.
• Security implication: Adaptive concurrency reduces retry noise, but ensure it doesn't mask underlying issues like persistent upstream failures that should be alerted on.

Suggestions for Improvement

• Add a section on monitoring adaptive concurrency metrics beyond the provided Grafana screenshots, such as key Prometheus metrics to watch.
• Consider including code snippets for function implementation that properly returns 429 for back-pressure.
• Test the post's instructions on a fresh OpenFaaS installation to confirm they work as described.
• Prioritize: Address potential silent failures from improper 429 handling to prevent production issues.

AI agent details.

Agent processing time: 33.337s
Environment preparation time: 10.452s
Total time from webhook: 57.442s