Cassandra Bundle Laravel Package

Technical Evaluation

Architecture fit — framework mismatch is still the headline issue, and v1.8.0 does not change it. This remains a Symfony2/Symfony3 bundle: a Bundle subclass, a DI Extension with a TreeBuilder config tree, and YAML service definitions consumed by Symfony's kernel at boot. Laravel has no Symfony kernel, no bundle registration, and does not read Resources/config/services.yml. Laravel's container is Illuminate\Container, not Symfony\Component\DependencyInjection. It cannot be composer required and auto-discovered into a Laravel app — every service must be re-registered manually in an Illuminate\Support\ServiceProvider. Its reusable value is the thin wrapper around datastax/php-driver (session construction, config surface, consistency/retry settings) plus, as of v1.8.0, a CQL table-option surface covering comment, speculative_retry, additional_write_policy, gc_grace_seconds, bloom_filter_fp_chance, default_time_to_live, compaction, compression, caching, memtable_flush_period_in_ms, and read_repair.

Integration feasibility — moderate, still only as a reference implementation, but the harvest value has increased. The underlying datastax/php-driver remains a composer stub for a PECL C extension (cassandra) linking against the DataStax C++ driver, so adoption is not a composer operation — it needs a PECL build in every image, a compiled toolchain in CI, and matching PHP ABI versions. The bundle's own logic is slim, and porting the useful surface into a ServiceProvider plus config/cassandra.php is roughly a few hundred lines. v1.8.0 adds a second, separable artifact worth harvesting: the enumerated table-option vocabulary and whatever serialization it applies to map-valued options (compaction, compression, caching) and boolean-ish options (read_repair, speculative_retry). That vocabulary is directly liftable into our schema grammar regardless of which driver we end up on.

Technical risk — high, and now four places rather than three.

1. Abandonment — signal is mixed, not resolved. The prior assessment cited a last release of 2019-04-15; v1.8.0 contradicts that. Treat the earlier date as stale and re-verify, but do not over-read a single release: a version bump with a one-paragraph description and no changelog, migration notes, or linked diff is weak evidence of sustained maintenance. Bus-factor-1 still applies. What v1.8.0 does establish is that someone is still touching the repo, which marginally improves the odds of an upstream fix — and should not be budgeted as if it were a support contract.
2. Driver deprecation. Unchanged and still the go/no-go gate. DataStax deprecated the PHP driver; releases stalled around the PHP 7.x era. A Laravel 10/11 target (PHP 8.1+) may have no working extension build at all.
3. Version-coupling of the new DDL surface. additional_write_policy and read_repair are Cassandra 4.0-era options. Their presence implies the package now assumes a 4.x-compatible cluster and CQL protocol. If our cluster is older, or is ScyllaDB (which supports only a subset of these options), the new feature may emit DDL that fails at runtime rather than at review. Unknown whether the package version-guards, validates, or blindly passes options through — and blind pass-through is the likely implementation for a package of this size.
4. Framework drift. Unchanged; the Symfony-side code targets 2/3 conventions and will not map cleanly onto modern Symfony components.

Key questions.

• New in v1.8.0: Is the table-option support a fluent schema builder (Laravel-style Schema::create analogue), a raw options array pass-through, or ALTER TABLE support only? Does it cover CREATE KEYSPACE/CREATE TYPE/indexes, or tables only?
• Does v1.8.0 alter the bundle's DI config tree or service definitions in a way that invalidates the porting surface we inventoried? No changelog means we must diff before porting.
• Are table options validated, version-guarded, or passed raw? What happens on a cluster that does not recognise additional_write_policy or read_repair?
• Which Cassandra/Scylla versions does 1.8.0 claim to support, and does that match our target cluster? This is now a second compatibility axis alongside the extension ABI.
• Does exposing DDL in application code imply we are accepting app-deploy-driven schema changes, or do we keep schema authority in a separate migrations path? (Decide before porting — see sequencing.)
• What is the actual business requirement driving Cassandra? If it is time-series or write-heavy event data, a narrower integration beats adopting any bundle.
• Which PHP runtime are we targeting, and has the cassandra extension been proven to build on it in our base image?
• Is the cluster self-managed Cassandra, ScyllaDB, or a managed service — this determines whether a pure-PHP CQL client is a viable escape hatch.
• Who owns the driver build and upgrade path internally? If "nobody yet," that is the real cost.
• Does our data model already exist, or will Laravel developers be designing CQL tables and their table options?

Integration Approach

Stack fit — reframe from "adopt" to "harvest," now with two harvest targets. This repository is a design reference, not a dependency. Take (a) its config schema — contact points, port, keyspace, consistency level, retry policy, timeouts — and session-construction pattern, and (b) the v1.8.0 table-option vocabulary and its serialization rules. Discard the Symfony bundle class, DI extension, and service YAML. The deliverable is a first-party CassandraServiceProvider + config/cassandra.php + a CassandraSession singleton binding, plus, if DDL is in scope, a first-party schema grammar. Owned by us, version-pinned in our own repository.

Migration path. Nothing is currently installed, so there is no migration. The path is spike → port → bounded rollout: (1) throwaway Laravel app in a container with the PECL extension to prove the runtime; (2) port session/config logic into a service provider; (3) hide the driver behind a CassandraClient interface; (4) decide schema authority — see sequencing — and only then port the table-option surface; (5) use it in exactly one bounded context; (6) only then allow a second consumer. Steps 1–2 are days, not weeks, because the source surface is small. Step 4 is the new work item and is not purely mechanical: it requires a policy decision before any code is written.

Compatibility. Three independent axes now need pinning, not two: the extension's PHP ABI compatibility, the CQL protocol version against the cluster's Cassandra/Scylla release, and table-option availability per cluster version/Scylla. The third is new and fails differently — ABI mismatches fail at boot, but an unsupported table option fails at DDL execution, which may be a deploy step or a first-write path. If the extension is unavailable on our target PHP, the fallback remains a pure-PHP CQL binary-protocol client (duoshuo/php-cassandra), which removes the build toolchain at some throughput cost. The CassandraClient interface preserves that option without rewriting call sites. Do not let the driver choice leak into application code, and do not let the table-option vocabulary leak either — wrap it.

Sequencing. The go/no-go on the extension build still precedes everything. v1.8.0 inserts one new gate after that passes and before the DDL port: confirm our cluster version supports the options we intend to expose, and confirm we intend to expose table options from application code at all. If the answer to the second is "no, schema changes go through a separate reviewed path," skip the DDL port entirely — the config/session port is unaffected by this release. Do not let the arrival of a new feature pull DDL into scope by default. If the extension build fails, the decision pivots entirely and all downstream effort — including any DDL work — is saved.

Operational Impact

Maintenance. All maintenance is ours. Vendor the ported code into the application or a private package; do not depend on the public repo. Pin the extension version explicitly in the image build and treat extension upgrades as change-controlled events requiring a rebuild and driver-level regression pass. v1.8.0 adds churn to track: if we adopt the table-option surface, we inherit the obligation to track which options exist per cluster version as Cassandra and Scylla evolve — that is a maintenance stream, not a one-time lift.

Support. No upstream support channel, no maintainer responsiveness, no security backfill. One release with no changelog does not constitute a support relationship. If a CVE lands in the C++ driver or the extension, we patch or fork. This needs to be an explicit accepted risk with a named owner.

Scaling. Cassandra scales horizontally; the constraint is PHP's process model. PHP-FPM workers are short-lived, so naive per-request session construction causes connection churn and a connection storm under load. Persistent sessions or session reuse are mandatory, and pool sizing must derive from FPM worker count × node count. New consideration: table-level compaction, compression, and caching are cluster-wide performance levers, not client-side settings. Making them settable from application code means an application deploy can change read/write amplification for the whole cluster. Benchmark before scaling the worker pool, and before the first DDL change lands.

Failure modes. Enumerated for runbook use:

• Extension absent or ABI-mismatched at runtime → fatal error on boot (fail fast; surface at deploy, not first query).
• Cluster unreachable → silent latency spike unless timeouts and retry policy are explicitly configured.
• Consistency-level defaults inherited from the bundle's config may not match our durability requirements.
• Unsupported or invalid table option on our cluster version → DDL failure at deploy time; if DDL runs inside application code, this becomes a failed request rather than a failed pipeline. Highest-value case to test.
• Misconfigured gc_grace_seconds, compaction, or bloom_filter_fp_chance → silent tombstone accumulation, read amplification, or repair-window surprises weeks later, with no application-level error. These are the failure modes that get misdiagnosed as infrastructure problems.
• default_time_to_live set at table level silently expires data. A data-loss-shaped failure that will first present as an application bug. Requires deliberate sign-off, not a default.
• Misconfigured speculative_retry or read_repair → latency or consistency anomalies with no client-side signal. Low observability; document expected values.
• DDL authored in application code → schema drift between environments, now with a larger blast radius than before this release. The prior "no schema-migration tooling" gap is not closed by v1.8.0 — a table-option surface is not versioned migrations, and it can make drift faster and easier.
• Profiler/data-collector path (if ported) must be disabled in production to avoid per-query overhead.

Ramp-up. The dominant people risk remains data modeling, and v1.8.0 broadens it slightly. Cassandra is query-first and denormalized; developers arriving from Eloquent will normalize and then hit partition-scan cliffs that look like infrastructure problems. Add a short module on table options and their operational semantics — specifically that these knobs do not fail loudly when wrong, and that several of them are irreversible in practice without a table rebuild. Budget enablement before the first consumer ships. The library API itself is small enough that ramp-up is under a day for anyone comfortable with Laravel service providers; the new options surface adds vocabulary, not complexity, but that vocabulary carries cluster-level consequences.