Skip to content

feat(metrics): add souin_shared_response_counter for request coalescing visibility - #835

Open
sgoroshko wants to merge 6 commits into
darkweak:masterfrom
sgoroshko:master
Open

feat(metrics): add souin_shared_response_counter for request coalescing visibility#835
sgoroshko wants to merge 6 commits into
darkweak:masterfrom
sgoroshko:master

Conversation

@sgoroshko

Copy link
Copy Markdown

Why

We rely on Souin's singleflight-based request coalescing to protect our upstream
during concurrent cache-miss stampedes (one leader request fetches, the group
shares the response). This is an important reliability mechanism for us, but it
was invisible on our dashboards — we only had cache hit/miss counters, with no
way to see how many concurrent requests were actually deduplicated.

What

Adds a new Prometheus counter, souin_shared_response_counter, incremented once
per "follower" request that reused a leader's response instead of calling the
upstream itself.

  • Registered alongside the existing counters in pkg/api/prometheus/prometheus.go
  • Instrumented in SouinBaseHandler.Upstream() (cache-miss path). A local
    executedUpstream flag distinguishes the leader from followers, since
    singleflight's shared return value is also true for the leader when at
    least one follower joined — a naive if shared would over-count by one per
    coalesced group.
  • A follower that ends up making its own upstream call anyway (private/
    Set-Cookie response, or Vary mismatch) is correctly not counted.
  • Revalidation-path coalescing (Revalidate()) is intentionally out of scope —
    can be a follow-up if needed.

Testing

  • New test fires N concurrent requests at the same cache-miss key and asserts
    the counter increases by exactly N-1.
  • Full existing test suite + go vet pass.

Docs

Added the metric to the Prometheus API table in README.md.

sgoroshko and others added 6 commits July 14, 2026 22:08
Records the design for a new Prometheus counter that tracks how many
concurrent requests reuse a singleflight leader's response during a
cache-miss, so this is visible next to the existing hit/miss graphs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task-by-task plan covering metric registration, the executedUpstream
follower-detection fix in Upstream(), test coverage, and README docs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ed followers

Track whether the singleflight closure actually executed the upstream
call (executedUpstream), since singleflight's shared flag is also true
for the leader when at least one follower joined. Only followers now
increment the new counter.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…rs only

Fires 3 concurrent requests at the same cache-miss key and asserts the
counter increases by exactly N-1 (followers only, not the leader).
Uses a per-run unique URL since the default storer lives in a
process-wide registry and would otherwise turn repeated runs into
cache hits.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@netlify

netlify Bot commented Jul 14, 2026

Copy link
Copy Markdown

Deploy Preview for teal-sprinkles-4c7f14 canceled.

Name Link
🔨 Latest commit 41e9552
🔍 Latest deploy log https://app.netlify.com/projects/teal-sprinkles-4c7f14/deploys/6a5690f660c2dd000881a449

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant