Cloud Pubsub Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging infrastructure: This is the official, GA PHP client for a fully managed message bus. Buying means no brokers to patch, scale, or page on; the "build" alternative (Redis/Horizon, RabbitMQ on VMs, self-hosted Kafka) trades a free license for permanent operational ownership.
• Queue architecture for Laravel: Choosing whether background work stays on Laravel's native queue drivers (database/Redis/SQS) or moves to Pub/Sub. Pub/Sub gives at-least-once/exactly-once delivery, ordering keys, configurable ack deadlines, retention up to 31 days, and replay/seek — capabilities Redis queues don't offer without custom code.
• Event-driven decomposition (roadmap): A credible path from monolith-with-jobs → fan-out event bus (one publish, N subscribers), which unblocks splitting services without rewriting the producers.
• Reliability roadmap: Dead-letter topics, retry policies, and replay make "we lost the job" incidents addressable as configuration rather than a new queue library.
• Platform consolidation: Standardizing async messaging across PHP services and non-PHP services (Pub/Sub is language-agnostic), or staying all-in on the cloud vendor we already use.
• Data/analytics roadmap: BigQuery and Cloud Storage subscriptions, plus schemas (Avro/Protobuf) and message transforms — including AI-inference transforms (v2.17+) — let us add sinks and lightweight enrichment without building consumers.
• Sourcing/risk decision: Apache-2.0, Google-maintained, GA with an explicit no-breaking-changes-in-minor/patch promise, PHP 8.4 compatibility, and a steady release cadence (recent versions add transforms, Kafka ingestion sources, Bigtable config). Low license and abandonment risk; low ecosystem mindshare (93 stars, 0 listed dependents) means we own the integration glue.

When to Consider This Package

• Adopt when: we are already on GCP (Cloud Run/GKE/Compute with workload identity), need durable cross-service events or fan-out, expect bursty or unpredictable throughput, or need replay/DLQ/retention guarantees beyond a Redis queue.
• Adopt when: multi-language producers/consumers are on the horizon, or audit-grade delivery/retention matters (message retention, schemas, transforms).
• Adopt when: we can absorb the integration work — Laravel has no first-class Pub/Sub queue driver, so plan for a custom connector (or a community package) plus a PUBSUB_EMULATOR_HOST test harness in CI.
• Look elsewhere when: we are standardized on AWS (SQS/SNS/EventBridge) or Azure — the cross-cloud auth and egress tax outweighs the benefit.
• Look elsewhere when: the workload is simple, single-app, low-volume background jobs where the database or Redis queue is already good enough and free.
• Look elsewhere when: on-prem/air-gapped, strict data-residency outside GCP regions, or a policy against managed third-party messaging.
• Look elsewhere when: the team lacks PHP gRPC (ext-grpc) or GCP IAM/ADC skills — REST works, but you lose streaming pull, which is where the efficiency wins live.
• Watch-outs before committing: credential-option deprecations (keyFile/credentials options) and the v2.4.0 removal of accidentally shipped classes mean we must track a defined upgrade cadence; cost model is per-message and per-GB plus subscription storage, which needs modeling against Redis-on-a-VM before it's called "cheaper."

How to Pitch It (Stakeholders)

For executives: Pub/Sub is Google's managed messaging service; this package is the official, free, Apache-2.0 PHP client. It lets us move background jobs and service-to-service events onto infrastructure Google operates — no brokers to run, built-in retries, dead-letter queues, 31-day replay, and elastic scale for traffic spikes. Cost shifts from engineering headcount to usage fees; the trade-off is deeper GCP dependence and a migration project rather than a drop-in swap.

For engineering: It's a generated, GA client with stable versioning and active releases (PHP 8.4 supported, recent additions include schema/transform support and Bigtable/BigQuery subscriptions). It supports gRPC for streaming pull (best throughput) with REST as fallback, an emulator for local dev and CI, and standard ADC auth on GCP. The real work is not the client — it's writing a Laravel queue connector + subscriber worker with proper ack/nack and idempotency, since nothing native exists.

Ask: a time-boxed spike (roughly 1–2 weeks) to build a thin queue driver, benchmark against our current Redis setup on cost and latency, and validate the emulator-based test path — then a go/no-go on migrating one non-critical job pipeline first.