Purgatory Bundle Laravel Package

Product Decisions This Supports

• Caching architecture: TTL-only vs. tag-based invalidation. This bundle is a working reference for the second option — responses get tagged, writes trigger a purge by tag. It lets us evaluate "aggressive edge caching + surgical invalidation" without a research spike, and gives a concrete answer to "can we cache this and keep it fresh?"
• Build vs. buy vs. borrow for purge orchestration. Purgatory is a thin abstraction over Varnish-style purgers. That makes it a useful benchmark: if our own purge client would be meaningfully simpler, build it; if it converges on this shape, borrow the design.
• Content-freshness as a shippable feature. Instant unpublish/takedown, price and inventory updates, editorial corrections, live scores — all historically blocked by "the cache makes it stale." Invalidation capability converts those from "next deploy" to "next sprint."
• Backend strategy / vendor leverage. Support for multiple backends (Varnish and friends) informs whether we standardize on Varnish + xkey/ban, or on CDN-native tag purge (Fastly surrogate keys, Cloudflare cache tags). The abstraction shows where backends genuinely differ and where the leaks are.
• Roadmap sequencing. Edge caching must not ship before an invalidation story. This defines the prerequisite workstream and its acceptance criteria (purge latency, tag coverage, blast radius of a bad purge).
• Framework caveat for this decision: the package is a Symfony bundle, not Laravel. On a Laravel roadmap it is prior art and a design contract, not a drop-in dependency — budget a port (roughly: one middleware to emit tags, one job/command to dispatch purges) rather than an install.
• Representative use cases: read-heavy, write-light workloads with strict freshness — sports/live data, catalog and pricing, CMS publishing, cacheable page fragments with per-entity tags.

When to Consider This Package

Evaluate seriously when:

• The stack is Symfony, or you're willing to run a small Symfony service as a purge sidecar.
• You already run a reverse proxy or CDN with tag/surrogate-key purge semantics.
• The read:write ratio is high enough that full-cache flushes are expensive (origin spike, thundering herd) and per-object invalidation pays for itself.
• You need one uniform purge API across multiple backends, or expect to migrate backends and want the call sites insulated.
• The team is small and would rather adopt a battle-tested tag/invalidation pattern than invent tag taxonomy and purge semantics from scratch.

Look elsewhere when:

• Laravel-only shop. There is no native integration; a response-cache package plus a CDN purge job is a shorter, better-supported path. Use purgatory as a design reference only.
• Traffic is modest or 30–60s TTLs are acceptable. The machinery is premature; staleness tolerance is a cheaper lever than invalidation.
• You need guarantees the bundle doesn't offer: durable purge delivery, ordering, audit trails, multi-region purge fan-out, or retry/backoff semantics. That's an eventing/queue product, not a bundle.
• Maintenance risk tolerance is low. 119 stars, single-organisation origin (Sofascore), a low opportunity score (~1.78), thin external contributor base, no commercial support. MIT means legal isn't the blocker — bus factor is. Verify release cadence and issue responsiveness before making it a hard dependency, and treat the future-dated last release as a data-quality flag to confirm, not a maturity signal.

How to Pitch It (Stakeholders)

Executives. "We can serve pages from the edge — fast, cheap, resilient — without ever showing stale content. This is a pattern proven at a high-traffic sports site, where freshness is the product. Adopting the pattern removes the last real objection to our caching investment and lets us commit to near-instant content freshness in customer-facing terms." Position it as infrastructure cost avoidance and risk reduction, not a new vendor or license line.

Engineering. "It's a Symfony bundle; our Laravel stack means we lift the pattern, not the package — tag on write, purge by tag on publish, one middleware and one job. In exchange we get a validated contract for tag semantics and backend abstraction, which saves us the design argument. MIT-licensed. We wrap it behind our own purge interface and keep the client swappable, so a maintenance stall costs us a sprint, not a migration. We do not fork it."

Product and ops. "Takedowns, corrections, and price or stock changes go live in seconds instead of waiting for a TTL. No more full-site flushes that spike origin load during exactly the moments we can least afford it. The trade-off we're accepting: purge is best-effort in this class of tooling, so anything requiring a hard guarantee gets a short TTL or a direct read as a backstop."