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

[derek]

Thank you for your contribution. unfortunately, one or more of your commits are missing the required "Signed-off-by:" statement. Signing off is part of the Developer Certificate of Origin (DCO) which is used by this project.

Read the DCO and project contributing guide carefully, and amend your commits using the git CLI. Note that this does not require any cryptography, keys or special steps to be taken.

💡 Shall we fix this?

This will only take a few moments.

First, clone your fork and checkout this branch using the git CLI.

Next, set up your real name and email address:

git config --global user.name "Your Full Name"
git config --global user.email "you@domain.com"

Finally, run one of these commands to add the "Signed-off-by" line to your commits.

If you only have one commit so far then run: git commit --amend --signoff and then git push --force.
If you have multiple commits, watch this video.

Check that the message has been added properly by running "git log".

[reviewfn]

AI Pull Request Overview

Summary

• Introduces a new blog post detailing the adaptive concurrency feature in OpenFaaS queue-worker
• Explains the differences between synchronous and asynchronous invocation modes
• Compares greedy vs. adaptive dispatch algorithms with diagrams and performance data
• Provides practical examples and deployment instructions for users
• Includes use cases for functions with concurrency limits or variable upstream capacity
• Adds supporting image assets including SVGs and Grafana screenshots
• Links to related documentation and further reading resources

Approval rating (1-10)

9/10 - Technically accurate, well-structured documentation that effectively communicates complex concepts with clear examples and visuals.

Summary per file

Summary per file

File path	Summary
_posts/2026-03-13-adaptive-concurrency.md	Comprehensive blog post on adaptive concurrency feature
images/2026-03-adaptive-concurrency/async-flow.svg	SVG diagram illustrating asynchronous invocation flow
images/2026-03-adaptive-concurrency/grafana-load-replicas-and-status.png	Screenshot showing load, replicas, and status codes
images/2026-03-adaptive-concurrency/grafana-queue-depth-and-inflight.png	Screenshot demonstrating queue depth and inflight trends
images/2026-03-adaptive-concurrency/greedy-vs-adaptive-diagram.svg	SVG comparing greedy vs adaptive dispatch
images/2026-03-adaptive-concurrency/greedy-vs-adaptive.png	Image with side-by-side performance comparison
images/2026-03-adaptive-concurrency/sync-flow.svg	SVG diagram illustrating synchronous invocation flow

Overall Assessment

The pull request successfully adds high-quality documentation for the adaptive concurrency feature, providing users with a thorough understanding of its benefits, implementation, and use cases. The content demonstrates technical depth while remaining accessible, with appropriate visuals and practical guidance. No major issues identified, but minor consistency improvements recommended.

Detailed Review

Detailed Review

_posts/2026-03-13-adaptive-concurrency.md

Front Matter Issues:

• Filename uses date 2026-03-13 but front matter specifies date: 2026-03-16. While Jekyll can handle this, recommend aligning the dates for consistency to avoid potential confusion in version control or publishing systems.

Technical Accuracy:

• The explanation of synchronous vs asynchronous invocation is clear and accurate, correctly describing the queue-worker's role with NATS JetStream.
• The adaptive concurrency algorithm description appears technically sound, with a logical feedback-driven approach. The steps (start low, increase on success, back off on rejection, etc.) are well-explained and match expected behavior for such systems.
• Performance claims (50% faster completion, fewer retries) are supported by the included data and diagrams, though consider adding more details about the specific test conditions in future updates.

Content Structure:

• The post follows a logical flow from problem statement to solution to practical application, making it easy to follow.
• Use cases are well-chosen and realistic (PDF generation, ML inference, data ETL), with good examples of both known limits and variable capacity scenarios.
• The comparison section with greedy vs adaptive is effective, supported by concrete metrics and visualizations.

Code Examples:

• The faas-cli store deploy command appears syntactically correct with appropriate labels and environment variables.
• The hey load testing command is a reasonable choice for demonstrating batch processing.
• Consider adding error handling examples or troubleshooting tips for when adaptive concurrency encounters issues.

Links and References:

• Internal links to other blog posts appear properly formatted. Recommend verifying these paths exist in the current documentation structure.
• External documentation link to queue-worker docs should be checked for accuracy against the current release.

Style and Editorial:

• Content appears to follow the mentioned editorial and style guide, with consistent formatting and professional tone.
• The writing is clear and engaging, avoiding unnecessary jargon while explaining technical concepts.
• Consider adding a brief section on potential edge cases or limitations of adaptive concurrency (e.g., very short-running functions where overhead might be significant).

Image Files

SVG Diagrams (async-flow.svg, greedy-vs-adaptive-diagram.svg, sync-flow.svg):

• These appear to be properly referenced in the markdown and should enhance understanding of the concepts.
• Since these are new assets, ensure they follow any existing naming conventions or optimization practices for the site.

Grafana Screenshots (grafana-load-replicas-and-status.png, grafana-queue-depth-and-inflight.png, greedy-vs-adaptive.png):

• The screenshots are well-integrated into the explanation and provide concrete evidence of the performance improvements.
• Consider adding alt text or captions for accessibility, though this may already be handled by the site's image processing.

General Asset Concerns:

• All images are placed in an appropriately named subdirectory following the date-based convention.
• File sizes and formats appear suitable for web delivery, but recommend checking for optimization opportunities if the site has image processing pipelines.

Security and Performance Considerations

• The feature description appropriately addresses back-pressure handling and resource utilization, which are important for system stability.
• No security concerns identified in the documentation itself, as it describes existing queue-worker functionality.

Testing and Validation

• The PR mentions the post has been checked against the writing style guide, which is positive.
• For a technical blog post, consider adding validation steps or peer review notes to ensure all technical claims are verified against the actual implementation.

Recommendations:

• Align the filename date with the front matter date for consistency.
• Consider expanding on potential monitoring or debugging steps for users implementing adaptive concurrency.
• Verify all internal links resolve correctly in the published environment.

AI agent details.

Agent processing time: 33.131s
Environment preparation time: 10.45s
Total time from webhook: 56.894s