Ha Bundle Laravel Package

Product Decisions This Supports

• Defining what "available" means for the product. This package exists to keep an application serving traffic when the write-primary of a replicated database goes down — degrading to read-only replica traffic instead of throwing connection errors on every request. That directly informs the product decision behind an SLA: does "99.9% uptime" mean every page renders, or that browsing/search/catalog stay up while checkout and edits degrade with a clear message? Making that explicit is a product call, not an infrastructure one.
• Per-surface degradation policy. If writes stop, which surfaces must survive (browse, search, dashboards, reporting reads) and which should fail gracefully with an honest error (checkout, signup, uploads, profile edits)? This bundle forces the conversation: you cannot configure failover without deciding what "read-only mode" means to users.
• Read/write splitting as a capacity and cost lever. Routing reads to replicas is a cheap way to absorb read-heavy traffic (feeds, reporting, search-adjacent queries) before buying a bigger primary. That is a budget and roadmap decision as much as an engineering one, and it changes the unit economics of growth.
• Build vs. buy on database high availability. The realistic menu is: (a) managed HA database with built-in failover (RDS Multi-AZ, Aurora, Cloud SQL HA, Atlas), (b) a proxy tier (ProxySQL, MySQL Router, PgBouncer, Vitess), (c) application-level failover like this bundle, or (d) do nothing and page a human at 3am. This package only sits on branch (c) — and only for Symfony/Doctrine stacks, not Laravel.
• Incident cost modelling. App-level fallback converts a hard outage into a partial one. That shifts the expected cost of an incident from "all conversions lost" to "writes delayed, reads preserved" — which is exactly the input needed to justify (or decline) infrastructure redundancy spend.
• Roadmap sequencing and expiry dates. If the organization is heading to a managed HA database or a service mesh with retries and circuit-breaking, app-level failover is a stopgap with a known shelf life. That makes it fundable now only if the migration is more than a quarter or two away.
• Owning the vendor risk explicitly. Zero stars, zero dependents, no visible maintenance story. Adopting it is a decision to own the code — that belongs in the architecture review record with an owner and a review date, not buried in a sprint ticket.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Symfony (2.x/3.x-era) application with Doctrine DBAL's master/slave connection model, and a framework or ORM upgrade is not on the near-term roadmap. For a Laravel codebase, the honest answer is that this is not an integrable dependency at all — there is no bundle bootstrapping, no Doctrine DBAL service-container contract, and Laravel's native read/write connection config already covers static splitting. In Laravel the package's value is as a reference design, not a dependency.
• Your database replication is self-managed (MySQL/MariaDB or Postgres primary plus replicas you operate), with no managed failover and no proxy layer in front of it.
• You have a concrete, measured pain: primary outages are producing full-site 500s, or read traffic is saturating the primary and replica routing would meaningfully reduce load.
• Your team is small, has no dedicated DBA, and can absorb ownership of a forked, vendored copy — including tests and compatibility review against your DBAL version.
• The fallback behaviour is genuinely acceptable to the product: a read-only window is better than downtime for your users.

Look elsewhere when any of these are true:

• Laravel, or Symfony 5/6/7, or DBAL 3.x+. Doctrine now ships primary/replica configuration natively; a third-party wrapper adds risk for behaviour you already have. This bundle predates that and is not a safe fit.
• You are on, or moving to, a managed HA database. RDS Multi-AZ, Aurora, Cloud SQL HA, or a Patroni-managed Postgres already fail over below the application. Layering app-level failover on top creates two competing sources of truth about which node is primary — a split-brain footgun.
• You need actual promotion/failover. The bundle gives graceful degradation, not replica promotion. Automated promotion is a proxy/orchestrator problem (ProxySQL, Orchestrator, Patroni, Vitess), not a Symfony bundle problem.
• You need pooling, query-routing rules, or per-query hints. A proxy tier solves that generically and benefits every service, not just this PHP app.
• Adoption signals matter to your process. Zero stars, zero dependents, low maintenance score means no community, no CVE triage, no upstream fixes. If your org requires a supported dependency or an SBOM with a maintenance story, this fails review on day one.
• The real defect is a single point of failure in infrastructure. Don't buy an application-layer workaround for something you can fix once, centrally, for the whole fleet.

If you proceed at all, treat it as a spike: read the source, extract the fallback pattern, and reimplement the small piece you need in-house with tests — rather than adding the dependency as-is.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, effectively unmaintained open-source add-on that would let our PHP application keep serving read-only pages when our database's primary server goes down, instead of showing errors to every user. Customers never see it — it is insurance against one specific failure mode, and it only pays off if we run our own replicated database without a managed failover service. It is also built for Symfony, not our Laravel stack, so we cannot simply install it. My recommendation is not to adopt it as a dependency: use it as a reference design, and either (a) fund the proper infrastructure fix — a managed HA database or a proxy tier — or (b) if that budget is unavailable this quarter, have engineering implement the read-only fallback pattern directly in our connection layer, scoped to two to three sprints. That delivers the same degradation behaviour without inheriting an unsupported third-party component.

For engineering leadership:

• What it is: a Symfony bundle that wraps Doctrine's master/slave connection so an app can detect an unreachable write primary and degrade to replica reads (or a fallback master) rather than failing all traffic.
• Why it is attractive: tiny surface area, MIT licensed, and it encodes a degradation model that is genuinely hard to get right ad hoc — retry semantics, when to stop retrying, and how to keep a request alive in read-only mode.
• Why we shouldn't just take it: it is the wrong platform for our Laravel codebase (no bundle bootstrapping, no compatible DBAL integration path), and it carries zero stars, zero dependents, and no plausible upstream support. That means we own every line, including compatibility with whatever DBAL version we run. It is a fork, not a dependency — price it that way.
• What "good" looks like instead: Laravel's native read/write connection config for splitting, plus an infrastructure-tier failover (managed HA endpoint or ProxySQL/MySQL Router) for primary loss. That solves the same problem for every service we run, not just this app.
• Cost estimate if we choose the in-house pattern: roughly 2–3 engineer-weeks to implement fallback in our connection layer with tests covering primary-down, replica-down, and recovery/reconnect scenarios; plus ongoing ownership of a small amount of infrastructure-adjacent code most engineers will never touch.
• Recommendation: gate the decision against the database platform roadmap. If managed HA or a proxy tier lands within two quarters, do nothing here and put the effort into that migration. If it lands beyond that, fund the in-house fallback pattern, assign a named owner, and record the accepted risk with an expiry date. Close out this package as "not recommended: wrong platform, unmaintained, unproven."