home / skills / makfly / superpowers-symfony / rate-limiting

rate-limiting skill

safe

This skill helps implement resilient Symfony async workflows with idempotent handlers, retry policies, and observability for rate-limiting tasks.

npx playbooks add skill makfly/superpowers-symfony --skill rate-limiting

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.1 KB

---

name: symfony:rate-limiting
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Implement resilient Symfony async workflows with idempotency, retries, and operational visibility. Use for rate limiting tasks.
---

# Rate Limiting (Symfony)

## Use when
- Implementing asynchronous workflows with Messenger/Scheduler/Cache.
- Stabilizing retries and failure transports.

## Default workflow
1. Define async contract and delivery semantics.
2. Implement idempotent handlers and routing strategy.
2. Configure retries, failure transport, and observability.
2. Validate success/failure replay scenarios.

## Guardrails
- Assume at-least-once delivery, not exactly-once.
- Keep handlers deterministic and side-effect aware.
- Surface poison-message handling strategy.

## Progressive disclosure
- Use this file for execution posture and risk controls.
- Open references when deep implementation details are needed.

## Output contract
- Async config/handlers updated.
- Retry/failure policy decisions.
- Operational validation evidence.

## References
- `reference.md`
- `docs/complexity-tiers.md`

Overview

This skill helps implement resilient Symfony asynchronous workflows focused on rate-limited tasks. It provides practical guidance and automated configuration steps to enforce idempotency, controlled retries, and operational visibility for Messenger, Scheduler, and Cache-based workflows. The goal is stable processing under at-least-once delivery semantics and clear failure handling.

How this skill works

The skill inspects async contracts, handler implementations, and routing to ensure they follow deterministic and idempotent patterns. It proposes retry and failure-transport configurations, surfaces poison-message strategies, and produces operational validation checks to prove replay and recovery behavior. Outputs include updated async config, retry/failure policy decisions, and evidence artifacts for operational sign-off.

When to use it

Building or stabilizing async workflows that use Messenger, Scheduler, or cache-backed delivery.
Introducing rate limits to downstream systems or APIs consumed by background handlers.
Hardening retry behavior and failure transports to avoid cascading failures.
Preparing operational validation for deployments that require predictable replay behavior.
Designing systems where at-least-once delivery semantics must be safely handled.

Best practices

Design handlers to be idempotent and avoid hidden side effects; assume messages may be delivered more than once.
Prefer deterministic processing and explicit state checks rather than relying on external implicit locks.
Define clear retry policies and a separate failure transport for poison messages with monitoring attached.
Apply rate limiting at the handler or transport layer to protect downstream services and smooth load spikes.
Document and validate replay scenarios with logs, traces, and example message replays before production rollout.

Example use cases

Rate-limiting outgoing API calls from Symfony Messenger consumers to comply with third-party quotas.
Stabilizing a scheduled job pipeline where occasional external failures trigger retries and need controlled backoff.
Configuring a failure transport and monitoring for poison messages to avoid silent data loss.
Validating idempotency of handlers by replaying messages in a staging environment and capturing operational evidence.

FAQ

What delivery semantics should I design for?

Design for at-least-once delivery; implement idempotency and detection of duplicate processing rather than relying on exactly-once guarantees.

Where should rate limiting be applied?

Apply rate limiting either at the transport layer or inside handlers before calling downstream services, depending on where you can most effectively control concurrency and throttling.