Probabilistic Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package wraps pouya1364/probabilistic-php in a Symfony bundle, not a Laravel package. Laravel is built on Symfony components, not the Symfony framework, so bundle auto-registration, the Kernel, and Symfony's DI extension mechanism are not available out of the box.
• The core value proposition is sound: config-declared, named instances of Bloom, Counting Bloom, Cuckoo, Count-Min, and HyperLogLog structures, resolved through a ProbabilisticRegistry plus per-instance autowired services. That is a clean seam and maps well onto use cases we actually have (dedup keys, "have we seen this?" checks, unique-visitor estimation, heavy-hitter/top-K, cache-stampede suppression).
• The probabilistic:list console command is a genuinely useful operational affordance for discovering what is configured per environment.

Integration feasibility

• Composer installation is straightforward; there is no exotic runtime requirement implied by the notes.
• The friction is configuration and container semantics: Symfony bundles expect YAML/XML config and framework bundle registration, while Laravel expects a ServiceProvider, PHP-array config under config/, and its own container. Neither the registry nor the autowired per-instance services will appear automatically in a Laravel app.
• Practical path is to consume the underlying library directly, or add a thin Laravel service provider that builds the registry from config/probabilistic.php. That is a small amount of glue, but it is our glue, not the vendor's.

Technical risk

• Maturity: v0.1.0 with no prior assessment and no data behind this review. Pre-1.0 means no SemVer stability guarantee on config schema, service IDs, or public classes.
• State semantics are undocumented in the release notes — the single biggest unknown. If filters are reconstructed per request/process, they are useless for most production dedup workloads; if they persist, the storage backend and serialization format become a critical dependency.
• Accuracy and sizing are not addressed: false-positive rates, capacity overflow behaviour, and memory footprint per configured instance are exactly the numbers a TPM needs before committing.
• Container cost: "per-instance autowired services" can mean many container entries; in a large app with dozens of named filters this is a startup and memory consideration.
• Bus factor / governance: no indication of maintainer depth, CI, or test coverage.

Key questions

1. Is filter state persisted between requests/processes, and via what backend (in-memory, Redis, filesystem, DB)?
2. What are the supported PHP and Laravel/Symfony version constraints?
3. Is there a first-party Laravel service provider, or is Laravel explicitly out of scope?
4. What is the measured false-positive rate and memory cost per 1M items for each structure?
5. What happens on capacity saturation — explicit error, silent degradation, or silent false positives?
6. Is the serialization/persistence format versioned, and what is the upgrade story when it changes?
7. What is the test coverage and CI posture? Any production references?
8. Are Symfony classes part of the public API surface we would be coupling to?

Integration Approach

Stack fit

• Treat this as a PHP library with Symfony-flavoured packaging. On a Laravel codebase, budget for an adapter layer rather than assuming drop-in.
• The abstraction we actually want — "give me a named probabilistic structure" — is well-matched to Laravel's container and config idioms; it just needs to be re-expressed.

Migration path

• Do not replace any existing exact-counting logic. Introduce alongside it, behind an internal interface (SeenBefore, CardinalityEstimator) so the vendor can be swapped.
• First adoption should be a single, tolerant, non-financial use case where a wrong answer is cheap: cache-stampede dedup, "already emailed this digest" checks, approximate unique-visitor counts.
• Pin the exact version (0.1.0) rather than a caret range; pre-1.0 caret ranges are how surprise breakage arrives.

Compatibility

• Config must be translated from the bundle's YAML/XML form into config/probabilistic.php.
• Autowired per-instance services need explicit container bindings (or a registry-only approach, which is simpler and sufficient).
• probabilistic:list should be re-exposed as an Artisan command if operators are expected to use it; otherwise it is dead weight on our stack.
• Version-lock interaction with our PHP and Laravel versions must be verified before the spike, not after.

Sequencing

1. Evaluate the underlying library (pouya1364/probabilistic-php) on its own merits, independent of the bundle — determine persistence, accuracy, and sizing answers.
2. Prototype a Laravel service provider (est. small, days not weeks) that reads PHP config and exposes the registry.
3. Pilot one tolerant use case in a non-critical path with a measurable success criterion (e.g., reduced duplicate work, bounded false-positive rate).
4. Harden: config validation, memory/capacity guardrails, observability (expose saturation metrics).
5. Expand to additional structures only after the persistence and sizing questions are settled.

• Do not sequence this ahead of higher-confidence work; v0.1.0 with an unresolved persistence question is a spike, not a roadmap item.

Operational Impact

Maintenance

• Assume we own the integration layer permanently. The vendor owns the data structures; the Laravel wiring is ours.
• Pin the version, watch upstream releases, and keep the internal interface thin enough that forking or replacing is a contained effort.
• Pre-1.0 packages can change config schema or class names in a patch release; treat every upstream bump as a review, not a routine update.

Support

• No stated SLA, support channel, or maintainer commitment. Internal ownership and documentation are mandatory before production use.
• If the underlying library stalls, the structures are well-understood algorithms — a fork is feasible, which is a meaningful mitigant.

Scaling

• Memory is the binding constraint. Each configured instance carries a fixed allocation proportional to capacity and target error rate; named instances multiply this. Sizing must be explicit per filter, not defaulted.
• Horizontal scaling requires shared, external state. If filters are per-process, every additional worker dilutes accuracy and breaks dedup semantics. Confirm the backend before designing for multi-instance deployment.
• Count-Min and HyperLogLog scale gracefully in footprint; Bloom-family structures need capacity planning up front and do not resize in place.

Failure modes

• Silent saturation: Bloom/Cuckoo filters at capacity degrade into false positives rather than errors. This is the dangerous failure — writes get dropped or dedup over-fires with no signal. Instrument saturation and alert on it.
• State loss on deploy: if state is in-process or on ephemeral disk, every deploy resets the filter, producing a burst of duplicate processing. Needs deliberate handling.
• False positives by design: downstream consumers must tolerate them. Any use where a false positive is a correctness bug (billing, entitlement, security allow-list) is out of scope.
• Config drift: YAML/PHP divergence across environments produces filters with different capacities in staging vs prod; validate config at boot.
• Serialization incompatibility after an upstream upgrade could silently invalidate persisted filters.

Ramp-up

• API surface is small; the registry pattern is easy for a Laravel engineer to pick up. The provider glue is a day or two of work.
• The real ramp-up is conceptual: the team must internalise that these structures trade exactness for memory, that capacity is a hard design input, and that false positives are a tunable cost rather than a bug. Without that, expect at least one production incident from an over-saturated filter.
• Recommend a short internal write-up covering capacity sizing, saturation monitoring, and the "when not to use this" list before the second team adopts it.