Laravel Request Tracker Laravel Package

Technical Evaluation

Architecture fit. dragon-code/laravel-request-tracker targets a narrow but real gap: correlating inbound HTTP requests with outbound inter-service calls in a Laravel estate. Architecturally it is a middleware-plus-model package — an inbound middleware stamps a correlation identifier, an outbound HTTP-client hook (Guzzle/Laravel Http facade) propagates it, and both sides persist a record to a database table. That model fits a conventional synchronous Laravel microservice or service-oriented monolith cleanly, because it rides on framework primitives we already own (middleware stack, HTTP client, Eloquent migrations). It does not replace an APM/tracing platform; it produces an application-level request journal, not spans, latency histograms, or a distributed trace graph. Position it as a complement (a first-party audit/correlation ledger) rather than a substitute for Datadog/New Relic/Sentry/Tempo.

Integration feasibility. Low code-footprint integration: composer require, publish config and migrations, register middleware, optionally configure header names and table. No agent, no sidecar, no infrastructure change — a meaningful advantage over instrumenting an OTel SDK for teams without collector infrastructure. Risks are less about difficulty than about maturity: 6 stars, 0 dependents, no ecosystem validation, and a version history we cannot treat as semver-stable by convention. There is no evidence of production case studies, and the release cadence/metadata should be verified directly against Packagist and the repo's commit history before we rely on it. MIT licensing is clean and gives us a fork escape hatch.

Technical risk.

• Adoption risk (high): effectively single-maintainer, unproven at scale, negligible community backstop. We would be an early adopter, not a follower.
• Data-sensitivity risk (high): request tracking packages frequently persist headers and sometimes bodies. Without verified redaction, we risk writing auth tokens, cookies, and PII into a queryable table.
• Performance/write-amplification risk (medium-high): a synchronous DB write per request per hop means fan-out multiplies write volume; the package is a logging path on the hot path of every call.
• Scope risk (medium): correlation likely stops at HTTP. Async boundaries (queues, scheduled jobs, event bus) are typically not propagated unless explicitly supported — our architecture is queue-heavy, so the "end-to-end" claim needs testing against real call chains.
• Lifecycle risk (medium): Laravel major-version lag, Octane/Swoole state leakage in middleware, and unannounced breaking changes.

Key questions for the maintainer / spike.

1. Supported Laravel and PHP version matrix, and stated BC policy?
2. Does it capture request/response bodies or headers by default, and is there a configurable redaction/allowlist?
3. Custom correlation header or W3C traceparent compatible? Can it interoperate with our existing tracing?
4. Is persistence synchronous or queued? Is sampling supported?
5. Does correlation propagate across queued jobs, events, and console commands?
6. Is it Octane-safe (no request state held in singletons)?
7. What is the retention/cleanup story — is there a prune command or is that ours to build?
8. Is the maintainer accepting issues/PRs, and what is the bus factor?

Integration Approach

Stack fit. Suitable if (a) services are Laravel 9+/PHP 8.1+, (b) inter-service traffic runs over the Laravel HTTP client or Guzzle rather than a bespoke transport, (c) we can allocate a dedicated datastore or table partition for the request log, and (d) we have an existing APM we are augmenting rather than replacing. It is a poor fit if the estate is polyglot with a mandatory single tracing standard, or if the latency budget on the critical path is already tight.

Migration path. Treat this as an additive, reversible instrumentation layer, not a migration:

1. Due diligence spike (1 week, one engineer). Read the source, verify the questions above, install in a sandbox app, and produce a one-page findings note plus a verdict.
2. Fork-and-pin. Vendor the repository under our org (MIT permits it), pin a commit, and require internal review before any upstream sync. This converts an unmaintained dependency into an internally-owned component with a defined upgrade path.
3. Pilot on one non-critical internal service in staging, then production shadow-mode for two weeks, comparing its correlation output against existing logs/APM. Success criteria: correlation IDs resolve across at least a 3-hop chain; p95 latency delta < 5 ms; PII scan of captured payloads clean.
4. Controlled expansion by service tier — internal tools first, then tier-2 services; explicitly exclude customer-facing high-QPS edge services until write volume and retention are proven.

Compatibility. Validate against: our Laravel/PHP matrix, MySQL vs PostgreSQL migration behavior, Octane/Swoole if used, Horizon/queue workers, and any existing middleware that mutates headers (proxies, API gateways, service mesh). Service mesh and ingress must be configured to preserve and trust the correlation header — otherwise the header is spoofable or stripped, which silently breaks the value proposition.

Sequencing. Dependency/license review → fork and pin → staging pilot with migrations and redaction config → verification of header propagation through ingress/egress → retention job and alerting → narrow production rollout → documented go/no-go for broad adoption at the end of a 30-day observation window.

Operational Impact

Maintenance. Plan for us to be the maintainer. Budget roughly 0.1–0.2 FTE of a Laravel-competent engineer in the first quarter for the fork, redaction rules, retention job, and upgrade testing; ~1–2 days per quarter thereafter. Track upstream releases manually; do not auto-merge. Assign a named owner, because an unowned fork of a 6-star package will rot.

Support. No vendor, no SLA, no community depth. Escalation is internal-only: whoever owns the fork. This must be explicit in the service catalog — teams will otherwise assume the platform team supports it. Document the "if it breaks, do X" runbook upfront, including the disable switch (unregister middleware) for fast rollback.

Scaling. The dominant cost is write volume: rows ≈ requests × average fan-out. Model it before rollout — a service at 200 rps with 3 outbound calls generates ~800 rows/s, ~70M rows/day. Mitigations: dedicated schema/database, time-based partitioning, mandatory retention (e.g., 7–30 days), sampling on high-volume paths, and async/batched writes if the package supports them. Without these, the feature becomes a database capacity incident.

Failure modes and blast radius.

• Datastore unavailable or slow → if persistence is synchronous, it becomes an availability risk on every request. Require fail-open behavior (log failure, never block the response) and verify it in code.
• Unbounded growth → disk exhaustion and query degradation; mitigate with partitioning plus a monitored prune job and a table-size alert.
• PII/secret capture → compliance exposure; mitigate with allowlist-only capture and a scheduled scan.
• Header trust misconfiguration → spoofed correlation IDs, misleading incident forensics.
• Laravel major upgrade → package lag blocks the platform upgrade; the fork is the mitigation, but it is unbudgeted work when it happens.
• Silent partial coverage → services instrumented on ingress but not egress produce broken chains that look like real gaps during incidents. Track instrumentation coverage as an explicit metric.

Ramp-up. Installation and first data are a half-day. Meaningful operational competence — reading the schema during an incident, tuning retention, understanding what is and isn't captured — is roughly 1–2 days per service team plus a short internal doc. The larger cost is organizational: convincing teams to instrument consistently and standardizing on the correlation header, which is a change-management effort, not a technical one. Given the adoption signals (6 stars, 0 dependents) and the availability of mature alternatives, my recommendation is a scoped pilot with a fork in hand, not a platform-wide commitment.