Cassandra Bundle Laravel Package

Technical Evaluation

• Architecture fit (verdict: reference design, not a dependency). Despite being filed alongside Laravel/PHP packages, this is a Symfony 2-era bundle: YAML-defined clusters/keyspaces/sessions, container-managed session services, a profiler data collector. There is no Laravel service provider here. A TPM's leverage is therefore indirect — it is a readable specification of the wiring our own Laravel integration layer must own: cluster/contact-point config, keyspace selection, connection-per-session lifecycle, consistency/retry/timeout policy, prepared-statement handling, and a query-observability hook.
• Integration feasibility: effectively zero as-is, high as a pattern. Four compounding blockers: archived repo, last release March 2020, zero dependents, and a foundation of datastax/php-driver (a PECL native extension, ext-cassandra) that is itself EOL. In a Laravel app the cost isn't composer require — it's compiling an abandoned C++-backed extension against a modern PHP toolchain, then reimplementing every Symfony container convention by hand. We would end up writing the Laravel bridge anyway, at which point the bundle contributes only the shape of the config and the service boundaries.
• Technical risk: high and asymmetric. Unpatched archived code, PHP 8+ incompatibility, Cassandra/CQL protocol drift, native extension build failures in CI and container images, and undocumented pool/reconnect behavior. The upside of adoption is at most a day or two of wiring; the downside is an unsupported native dependency inside our runtime with no upstream path. That ratio should be named explicitly in any decision record.
• Key questions for the spike owner: Which PHP runtime and driver path are we actually targeting — ext-cassandra (EOL) or a pure-PHP CQL driver? What Cassandra/ScyllaDB version and protocol level must we speak, and is the target managed (Astra, Keyspaces, ScyllaDB Cloud) where driver support is the binding constraint? Is the workload genuinely append-heavy write-by-known-key, or is there a hidden ad-hoc reporting requirement that invalidates Cassandra entirely? Who owns the schema/migration story, given the bundle creates no schema and no CQL surface? What is the exit plan and budget line for the driver decision? Is any current service already on this bundle — and if so, what's its PHP upgrade deadline?

Integration Approach

• Stack fit: Do not port. Harvest. Read DependencyInjection/Configuration.php and the connection wrapper in under an hour, and extract the option surface (contact points, port, keyspace, timeout, consistency, retry/load-balancing policy, protocol version, credentials, default page size) as the requirement list for a Laravel-native adapter. That list is the real deliverable; the code is not.
• Migration path: Build a thin CassandraConnection interface in the Laravel app with two or three methods we actually need (query, prepare/execute, maybe batch), bind it in a service provider, and keep CQL behind per-table-family repositories. This is a 1–3 day spike, not a procurement. Keeping the interface application-owned means the driver choice stays reversible — which matters a great deal when every candidate driver in this space is either EOL or thinly maintained.
• Compatibility: Validate before committing: does a working driver exist for our PHP version; does it negotiate our cluster's protocol level; do the container images build the extension reproducibly; does the CI runner have the toolchain. Also confirm that the keyspace exists — the bundle never created schema, and neither should our adapter; schema management belongs to an explicit migration/bootstrap step, not the ORM-equivalent layer.
• Sequencing: (1) Confirm the product decision first — is Cassandra the right store? If ad-hoc querying is anywhere on the roadmap, stop and pick Postgres/DynamoDB. (2) If yes, timebox a driver-viability spike before any application code. (3) Extract the config/option checklist from this bundle while doing it. (4) Land the adapter + repository pattern behind an interface, blocking direct driver use in feature code. (5) Put the driver choice on the architecture review calendar with a re-evaluation date tied to the next PHP major.

Operational Impact

• Maintenance: If we take the code, we own it permanently — archived means no security patches, no bug fixes, no PHP compatibility work, and 29 stars/0 dependents means near-zero community answers when something breaks. The cheaper ownership model is "we wrote 200 lines of our own adapter," which is roughly what this bundle is once you strip the Symfony 2 container plumbing. Budget for dependency scanning exceptions and a named owner either way.
• Support: No vendor, no upstream, no escalation path. For the Cassandra layer specifically, the operational burden is not PHP — it's compaction, repair, tombstones, and consistency tuning, none of which any framework glue solves. If the team lacks Cassandra ops experience, that is the dominant cost line and the bundle's existence is irrelevant to it. Prefer a managed Cassandra-compatible service so the ops burden is contractually owned.
• Scaling: The bundle is too thin to be the bottleneck; scaling behavior is that of the driver and the cluster. The PM-relevant risks are connection-pool sizing, per-request timeouts, backpressure under node loss, and observability. The built-in profiler collector is a Symfony debug-toolbar concept and does not translate to Laravel's Telescope/Horizon world — instrument the adapter directly, and treat query-latency and timeout metrics as an acceptance criterion of the spike, not a later enhancement.
• Failure modes: Native extension missing after a PHP upgrade (container boot failure — the single most common first-day failure), silent reconnect after a node drops, exception types that don't map cleanly to application error handling, and — for anyone actually consuming the bundle — container boot failure from stale service definitions. Each needs a runbook entry and a rollback plan, and none will ever get an upstream fix.
• Ramp-up: Scarce and depreciating. Few engineers carry current Symfony 2 bundle + DataStax PHP driver experience, and asking new hires to onboard onto archived dependencies is a retention and delivery risk. The mitigation is the same as the architecture: keep the Cassandra surface to an interface plus a handful of repositories, document the contract, and never let bundle internals leak into feature code — so the knowledge required to operate it stays small enough to fit in one person's head and one page of documentation.