Flare Daemon Laravel Package

Technical Evaluation

Architecture fit. The daemon moves third-party egress out of the Laravel request cycle: app code POSTs to a localhost HTTP endpoint, and a separate long-running ReactPHP process batches and forwards to Flare ingress. For a TPM the important property isn't throughput, it's that the failure mode is fail-open: if the daemon is unreachable, the Flare client falls back to direct delivery. That converts a hard dependency on a vendor endpoint into a soft one, which is what makes this shippable without a big-bang migration or a feature-flag programme.

The cost is explicit and should be written into the design record: buffers are in-memory only. We are trading latency relief for a bounded observability loss window. With a ~1s flush timer and a 10s safety-net flush (FLARE_DAEMON_FLUSH_AFTER_SECONDS), a SIGKILL or OOM kill can discard up to that window of errors, traces, and logs per API key and entity type. SIGINT/SIGTERM drain gracefully — so the loss surface is specifically ungraceful termination, not deploys done properly.

Integration feasibility. Low on the application side. Configuration is entirely environment variables, there is no service-provider wiring implied, and the Composer bin is a bundled PHAR with an isolated ReactPHP runtime. That is the single biggest feasibility unlock: adopting the daemon adds no ReactPHP or PSR-7 constraints to composer.lock, so it should clear dependency-governance review in monorepos where a new transitive graph constraint is a multi-week negotiation.

Technical risk.

• Pre-1.0 versioning. Current line is 0.3.x, so SemVer permits breaking changes. Pin minors or exact versions; treat upgrades as planned work, not patch drift.
• Local trust boundary. Default listener is 127.0.0.1:8787 and accepts payloads carrying Flare API keys. Anything co-resident on the host can POST. Verify bind scope in containerised and shared-host deployments, and confirm whether payload authentication exists at ingest — this is the question I'd escalate first.
• Per-host single point of failure. Correctness depends on the fallback path, which by construction is almost never exercised in production. Fallback must be monitored, not assumed.
• Quota behaviour is subtle and recently changed. 0.3.1 stopped pausing delivery on upstream 403 and made rate-limit 429s pause for a shorter interval than quota 429s. We need to know what a 403 now means and whether repeated 403s create a hot retry loop.
• Release-channel coordination. One canonical version stream fans out to Packagist, PHAR, Docker (v-prefixed tags) and Helm (plain SemVer with v-prefixed appVersion). Skew across four channels is a release-engineering risk we own, not a runtime bug.
• Adoption metadata is misleading. 0 stars / 0 recorded dependents understates exposure because the package installs transitively via Flare client packages. Do not use repository popularity as a proxy for either adoption or risk; use our own enablement ratio.

Key questions.

1. What is our acceptable report-loss budget, in seconds of buffer and payloads per incident, and does in-memory-only buffering meet it?
2. Is the local ingest endpoint authenticated or network-restricted beyond the default bind address?
3. What are the exact semantics of a 403 since 0.3.1 — permanent rejection, key revocation, misconfiguration — and does the client back off?
4. On upstream 429, does the daemon pause and drop, or pause and let the client fall back to direct delivery? The data-loss answer differs materially.
5. Who owns the enablement default — platform or application teams — given install-by-default is deliberate and enable-by-default is explicitly not?
6. What is the support matrix commitment across Docker and Helm, and who owns chart upgrades?
7. Does the FLARE_COMPOSER_LOCK watcher belong on in production as a drain-on-deploy hook, or only in development?
8. What is the deprecation path if we enable the daemon and later need to revert fleet-wide?

Integration Approach

Stack fit. Laravel applications consume this through Flare's client layer, so "integration" is really configuration plus a process to supervise. The PHP 8.1+ floor aligns with current Laravel support windows, and because the daemon core is framework-agnostic, it is insulated from Laravel release cadence — a genuine advantage for teams that upgrade the framework on a schedule.

The install/enable split is the key control. The package arrives by default via the client dependency, but transport activation is explicit. That means our dependency graph changes passively while behaviour changes only when we choose it. As TPM I would treat enablement as a deliberate, reversible configuration decision with an owner and a rollback instruction ("unset the daemon endpoint"), not as a package upgrade side effect.

Migration path — staged, with exit criteria.

• Wave 0 — inventory. Confirm presence (vendor/bin/flare-daemon), record PHP versions, hosting topology (VM vs container vs K8s), and current Flare p95 contribution to error-path latency.
• Wave 1 — local development and CI. Developer machines and CI smoke using --test mode and tests/test.sh. Exit: nobody's inner loop depends on the daemon to see an error.
• Wave 2 — staging, one service. Full path to real ingress with a real API key. Exit: /status buffer drains reproducibly; fallback observed at least once deliberately (kill the daemon mid-traffic).
• Wave 3 — one production service, single region. Exit: fallback rate measured near zero under normal operation, p95 improvement attributable, no increase in lost-report reports from support.
• Wave 4 — fleet. VM deployments via vendor bin under systemd/supervisor; Kubernetes via the DaemonSet chart.

Compatibility and rollback. Because fallback exists, a mixed fleet of daemon-enabled and direct-delivery services is safe — no flag day, no coordinated cutover. Rollback is a configuration revert, not a deploy, which keeps the blast radius of a bad rollout small and makes Wave 3 genuinely reversible.

Sequencing constraint. Observability must land before Wave 3, not alongside it. Concretely: /health and /status scraped into our existing monitoring, a fallback-rate metric, and a buffer-drain view. Shipping the daemon without those means we cannot tell "working well" from "silently falling back to the slow path."

Kubernetes specifics. The chart runs one pod per node with service.internalTrafficPolicy: Local, so application pods must resolve the endpoint on their own node. Sequencing must include node drain, cordon, and autoscaler scale-out tests — a new node that briefly lacks a daemon must fall back cleanly rather than fail error reporting.

Operational Impact

Maintenance. This adds a long-running process to a surface that, for most Laravel teams, has only ever been PHP-FPM and a queue worker. Supervised restarts, log rotation, and version pinning become real work. The PHP_MEMORY_LIMIT default of 128M plus in-memory per-key/per-type buffers means memory scales with burst volume against flush rate; the 256KB buffer-size threshold is a maintenance safety net, not backpressure against ingress. Capacity planning should treat it as a soft limit.

Support model. New failure surface needs a named owner. My recommendation: platform owns the daemon process, version pin, and chart upgrades; application teams own their Flare API keys, quota consumption, and enablement flag. Write the runbook before Wave 3 — "daemon down," "daemon wedged," "429 storm," "buffer not draining" — each with a decision: restart, revert to direct delivery, or escalate to vendor.

Scaling. The published figure — ~18,000 reports/sec with p95 under 11ms — is measured in --test mode, i.e. without upstream egress. Read it as an upper bound on ingest capacity, not end-to-end throughput. The real ceiling is Flare ingress and per-key quota. One daemon per node is the right shape; size against per-node peak, not cluster peak, so a single noisy node doesn't degrade reporting for its neighbours.

Failure modes and expected behaviour.

Ramp-up and success criteria. Enablement must be a documented, discoverable path — the intended onboarding steers users toward the daemon, especially for logging. For a 60–90 day window I would commit to four metrics: (1) error-path p95 improvement attributable to daemon adoption, (2) fallback rate below ~1% of daemon-enabled services under normal operation, (3) zero increase in lost-report incidents, and (4) enablement ratio across the fleet. Metric (2) is the leading indicator — sustained fallback means the daemon is decorative and we're paying operational cost for nothing.