Bitter Bundle Laravel Package

Technical Evaluation

Architecture fit. There is a naming mismatch that drives the entire assessment: rezzza/bitter-bundle is a Symfony Bundle, not a Laravel package. Its published value is DI wiring — registering Bitter\Client in Symfony's container and exposing YAML/PHP config for key prefix and Redis client. Laravel consumes none of that (no bundle registration, no Symfony config tree). The idea — Redis bitmaps, one bit per user per event per day, BITCOUNT/BITOP for uniques and cohort intersection — fits a Laravel stack fine. The package does not. Treat the bundle as a Symfony-only artifact and, for our purposes, as documentation for how to construct the underlying client.

Integration feasibility. Low as a dependency, moderate as a pattern. The real dependency is rezzza/bitter, which is framework-agnostic and small enough to reason about in an afternoon. A Laravel integration is a singleton in AppServiceProvider (new Client($redis->connection()->client())), an alias/facade, and a middleware for request-level tracking — roughly a day of work plus tests. That is the honest cost of "using" this package in Laravel: we re-implement the bundle's only real contribution (container wiring) in about twenty lines.

Technical risk. High, and concentrated in ownership rather than technology:

• Adoption signal is a warning, not a metric. 17 stars and 0 dependents mean no upgrade path, no issue triage, no one else hitting our bugs. Assume unmaintained.
• Version drift. A Symfony-bundle-era package likely targets older Symfony/PHP; the underlying library may too. Compatibility with our PHP version and Redis client is unverified until we spike it.
• Key design is load-bearing and invisible. bitter:{action}:{date} naming, TTL/expiry, and namespace/prefix behavior determine memory growth, tenant isolation, and whether counts are even correct. This is the thing that will bite us in month three.
• Semantic limits. Bitmaps answer "how many distinct users did X on day D" and intersections thereof. They do not answer "uniques by plan, country, and channel, filtered by signup date," and they store membership, not events — no funnels with arbitrary step ordering, no per-user timelines, no forensics.
• Accuracy contract. Bitmap counting is exact (not HLL-approximate) if the bit offsets are stable user IDs. Any ID recycling or renumbering silently corrupts historical counts.

Key questions.

1. Which PHP and Symfony versions does the bundle, and rezzza/bitter, actually support — and does the library run standalone with only a Redis client?
2. What is the key layout, prefix/namespace mechanism, and TTL story? Is expiry built in or left to us?
3. What is the client's API surface (track, count, set, and/or/not), and is it stable enough to depend on directly?
4. Which Redis deployment does it assume — single instance, cluster, Sentinel? Any assumptions about BITOP across slots?
5. How are bit offsets derived from user IDs, and what is the failure mode for very large IDs (sparse bitmap memory blowup)?
6. Is there any test coverage or CI we can trust, or are we validating correctness ourselves?
7. Where does the answer to "who is user 12345?" live? Bitmaps deliberately hold no PII — confirm that matches our privacy posture and that no one later expects user-level drill-down.

Integration Approach

Stack fit. Do not install the Symfony bundle. Depend on rezzza/bitter directly (or vendor a copy), behind an application-owned interface — e.g. AnalyticsBitmapRepository — so no controller, job, or middleware ever touches Bitter\Client directly. Provide a Laravel service provider, a Bitter facade for ergonomics, and config in config/analytics.php (connection name, key prefix, TTL, enabled flag). This costs little now and is the difference between swapping implementations later and rewriting call sites.

Migration path. If the bundle already exists in a Symfony service we depend on, isolate it behind an HTTP or queue boundary before touching anything; migrate consumers to the interface first, replace internals second. For a greenfield Laravel effort there is nothing to migrate — this is a build, and we should say so plainly rather than framing it as "adopting a package."

Compatibility. Verify against our pinned PHP version, our Laravel Redis connection abstraction (prefixing and serialization in particular — Laravel's key prefix will compose with Bitter's namespace, and double-prefixing is a classic bug), phpredis vs. predis support, and Redis 6/7 BITOP/BITCOUNT behavior under cluster. Confirm the library doesn't require a Symfony HTTP kernel or container to function.

Sequencing.

1. Spike (1–2 days): clone, run against a sandbox Redis, confirm the client works standalone on our PHP version and inspect real key layout with redis-cli --scan --pattern 'bitter:*'.
2. Interface + adapter: define AnalyticsBitmapRepository, implement with Bitter, add feature flag defaulting off.
3. Parity validation: run one real metric (e.g. daily active users) in parallel with an existing source for two weeks and reconcile counts exactly.
4. Constrain scope in writing: unique counts, DAU/WAU/MAU, D1/D7/D30 retention, feature-adoption flags. Anything requiring arbitrary segmentation routes to the warehouse by policy.
5. Roll out to one low-risk metric, then expand behind the flag.

Operational Impact

Maintenance. We own this. With zero dependents and no visible maintainer activity, budget for forking into our monorepo, pinning, and periodically re-validating against PHP/Laravel/Redis upgrades. Estimate is small per year but non-zero forever, and it lands on whoever owns analytics — assign that name before we start, not after.

Support. No community escalation path. Internal engineering is the only tier. Mitigate by keeping the surface tiny: a thin adapter over a small library is supportable; a fork with local patches spread across call sites is not. Document the key schema, TTL policy, and query semantics in the repo README so a future maintainer isn't reverse-engineering Redis keys.

Scaling. Genuinely attractive: ~10M daily actives is on the order of 1.25 MB of Redis per day per metric, versus gigabytes in a row-per-event table. That's the argument, and it holds — above roughly a few hundred thousand users. Below that, an indexed events table is cheaper in total cost of ownership once you price engineering time. Operationally, watch hot keys (a single daily bitmap for a high-traffic event is written constantly), avoid BITOP across cluster slots, partition by metric and time window, and set TTLs explicitly. Cardinality explosion from unbounded event names or recycled/miscomputed bit offsets is the failure that looks fine for months.

Failure modes. Redis outage or latency degrades analytics writes and reads; if tracking is inline in the request path, it becomes an availability problem — queue it or make it fire-and-forget, and never put it inside a DB transaction (bitmaps don't roll back). Double-prefixed or drifting keys produce silently wrong counts rather than errors, which is worse. Missing TTLs grow storage indefinitely. Cross-tenant key leakage is a real risk if the prefix scheme isn't enforced in one place. Missing bit offsets from ID overflow corrupt counts irrecoverably.

Ramp-up. Moderate. Engineers need Redis bitmap fundamentals (dense vs. sparse encoding, BITCOUNT ranges, BITOP semantics), Laravel service-container and facade conventions, and — for the spike — enough Symfony bundle literacy to read services.xml and learn what arguments Bitter\Client expects. The highest-friction skill isn't code, it's analytics correctness: knowing which questions bitmaps can and cannot answer, and validating that counts match reality before an executive quotes them in a review. Budget the parity-validation week; it is cheaper than a retraction.