Laravel Bloom Gate Laravel Package

Product Decisions This Supports

• Feature evaluation: Laravel Bloom Gate targets a specific optimization: avoiding SQL queries for known-absent values in Laravel read paths. It is relevant only where the negative-query ratio is high enough to matter.
• Roadmap: Treat this as a bounded pilot candidate, not a production commitment. It remains an evaluation release candidate; production deployment certification is explicitly out of scope.
• Build vs. buy: The package encodes non-trivial consistency behavior — trusted negatives, authoritative fallback, prepared-write coordination, lease/drain validation, commit/rollback handling, and rebuild. Building this internally is materially more complex than adding a Bloom filter. Buying/prototyping is reasonable, but the RC status, topology constraints, and writer-coordination requirements are adoption costs.
• Use cases to test: Read-heavy existence checks where most lookups miss — username/email availability, slug or route collision checks, SKU/ID existence, permission or feature existence. Do not position this as a general latency improvement or a benefit for all-present workloads.
• Success metrics: Define success as reduced SQL calls and capacity relief, not latency. The documented local workload reduced absent-value SQL queries from 1,000 to 8, but the Redis gate was slower than indexed MySQL/PostgreSQL/SQLite baselines. All-present queries avoided no SQL calls. Measure the target application’s datastore and negative-query ratio before enabling.
• Operational acceptance: The pilot now installs the exact selected source commit and emits bounded query and retained-lease measurements — use that for reproducible evaluation. Confirm Packagist registration/indexing and remote installation separately from the GitHub tag.
• Risk decisions: Writer drain reads reject inconsistent surviving lease/count evidence without repairing it. That is fail-fast integrity behavior, not self-healing; an operational runbook is required. Retained lease history increases drain validation cost in local measurements (roughly 0.16–0.20 ms with no retained leases to 2.33–2.86 ms with 1,000 released leases).

When to Consider This Package

Consider it when:

• You are on PHP 8.3+ and Laravel 12/13.
• The application has a measured, high negative-query ratio on read paths that can tolerate an approximate membership gate.
• You can use the documented durable standalone-primary Redis profile for trusted negatives.
• Every membership-entry writer for a coordinated mutable filter can participate in the prepared-write protocol.
• You can accept authoritative fallback and rebuild as part of normal operations.
• Retained lease history is short-running, not long-running.
• You are willing to pilot behind a feature flag with explicit metrics and a rollback path.

Look elsewhere when:

• You need a stable v1 or production deployment certification.
• You require Redis Cluster support.
• You have unobserved production deployments or cannot instrument the read/write paths.
• You rely on MongoDB integration; it is unverified.
• You cannot coordinate all writers on the prepared-write protocol.
• Your workload is dominated by all-present queries, or your primary goal is latency reduction.
• SQL comparison/collation cannot be aligned with the filter’s normalization semantics.
• You need long-running retained lease history at production scale.

How to Pitch It (Stakeholders)

Executive summary: Laravel Bloom Gate is a targeted query-avoidance layer for Laravel applications with many absent-value lookups. In one local 1,000-query workload, SQL queries fell from 1,000 to 8, but the Redis gate was slower than indexed database baselines and all-present queries avoided no SQL calls. This is not a general speedup. It is an evaluation release candidate, so the recommendation is a bounded pilot with clear metrics — not a production rollout.

Engineering summary: The package provides trusted negatives, authoritative fallback, prepared-write coordination, lease/drain validation, and rebuild behavior. Adoption requires a durable standalone-primary Redis profile, coordinated writers, and operational handling for fail-fast inconsistent lease evidence. Start with the exact release candidate commit, publish the config, instrument query avoidance and retained-lease measurements, and keep the gate behind a feature flag.

Decision requested: Approve a time-boxed pilot against a measured negative-query-heavy workload. Revisit production consideration only after stable release status, certification of the target topology, and pilot evidence showing meaningful SQL reduction without unacceptable operational overhead.