Laravel Redis Advisor Laravel Package

Technical Evaluation

Architecture fit

• Ships as a standard Laravel package (service provider + config publish), so it slots into the existing app skeleton without touching runtime data paths — it is explicitly read-only, which keeps it out of the request-serving critical path.
• Covers four surfaces a TPM typically owns as operational risk: queue health (eviction, backlog, Horizon trimming), key hygiene (cache:clear blast radius, prefix collisions, keys without TTL, big keys), server posture (persistence, memory, fragmentation, reachability) and session TTL drift against SESSION_LIFETIME.
• Supports both phpredis and predis, so it does not force a client migration on teams standardized on either.
• Three consumption modes match three audiences: redis-advisor:report (text) for engineers, --format=json for tooling, --fail-on for CI gating, and the Blade dashboard at /redis-advisor behind the viewRedisAdvisor gate for day-to-day visibility.

Integration feasibility

• Low-effort install (~composer require + optional config publish), no schema changes, no migrations, no queue/worker restarts required.
• The CONFIG-disabled fallback is the single most important design decision for our estate: managed providers (ElastiCache, MemoryDB, Upstash) block CONFIG GET, so a naive advisor would be useless there. Sourcing from INFO first and skipping unsupported checks with a stated reason means partial results are trustworthy rather than silently wrong.
• CI gating via --fail-on is the highest-leverage adoption point — it turns advisory output into a build-time guardrail with no on-call dependency.

Technical risk

• Pre-1.0 stability: v0.1.0 signals an unstable public API — config keys, check names, exit-code semantics and JSON schema may all change across minors. Pin the version and treat JSON output as non-contractual until a 1.0.
• Check coverage is provider-dependent: on ElastiCache/MemoryDB/Upstash, the CONFIG-gated checks (persistence config, fragmentation detail, some eviction policy verification) will skip. We should expect meaningful blind spots exactly on the managed infrastructure we care most about.
• Scan cost: key-space checks (no-TTL keys, big keys, prefix collisions) imply SCAN/MEMORY USAGE traversal. On multi-GB keyspaces this is O(N) and can add latency; needs a scheduling and sizing story before production use.
• Command permissions: read-only is not the same as permitted — ACL-restricted users may lack INFO, SCAN, MEMORY USAGE or DBSIZE. The advisor's failure mode in that case must be a clean skip, not an exception.
• Exposure surface: a web route, even gated and local-only by default, is a new externally reachable path if the gate is misconfigured or APP_ENV is wrong.

Key questions

1. Supported Laravel and PHP version matrix? Does it work on our oldest and newest supported apps?
2. What is the minimum Redis ACL command set required, and how does the advisor behave when a command is denied mid-run?
3. Are the SCAN-based checks bounded (count/cursor limits, sampling) or full keyspace walks? What is expected runtime on a 5–10 GB instance?
4. Does the tool understand cluster mode, Sentinel, and multi-database setups, or does it assume a single logical database?
5. How is Horizon trimming detected — config file, horizon:list-style introspection, or queue metrics? Does it degrade gracefully if Horizon is absent?
6. Is the JSON schema versioned/documented, and is --fail-on threshold-based or boolean per check?
7. Maintenance posture: single maintainer? Release cadence? Security disclosure path? Is read-only verifiable (no writes, no CONFIG SET)?
8. Does the web dashboard require auth beyond the gate, and can the route be fully disabled by config?

Integration Approach

Stack fit

• Fits any Laravel app already on Redis/Valkey for cache, queues or sessions — which is essentially the whole fleet. No new infrastructure, no agent, no sidecar.
• Complements existing observability rather than replacing it: it answers configuration-correctness questions that metrics dashboards (memory used, hit rate, queue depth) do not — TTL policy, prefix collision risk, session TTL drift, persistence configuration.
• Both phpredis and predis support means we do not need to fork the rollout by client.

Migration path

• No migration. This is additive and read-only: install, publish config, run redis-advisor:report in a non-production environment first, then staging, then production in report-only mode.
• Forbidden-command environments degrade to INFO-only output automatically, so no separate "managed Redis" edition or workaround is needed.

Compatibility

• Primary compatibility gate is the Laravel/PHP version matrix and Redis/Valkey version; confirm before fleet-wide rollout.
• The CONFIG-disabled path is a supported mode, not a degradation to be worked around — but the team must be briefed that skipped checks are expected on managed infrastructure and must not be read as "green."
• Exit-code and JSON contract should be treated as unstable pre-1.0; avoid wiring the JSON into long-lived tooling until it stabilizes.

Sequencing

1. Week 1 — Evaluate: install in one staging app per Redis provider type (self-managed, ElastiCache, Upstash). Capture skipped-check reasons to learn the real coverage ceiling per provider.
2. Week 2 — Baseline: run the text report against staging and production (read-only, manual, off-peak) and record findings. Triage the no-TTL-keys, prefix-collision and session-TTL findings into the platform backlog.
3. Week 3 — CI gate: add redis-advisor:report --fail-on=... to the pipeline for a small set of high-signal checks only (session TTL mismatch, keys without TTL). Expand incrementally.
4. Week 4 — Dashboard: enable the Blade dashboard in local/dev only; decide explicitly whether to enable in staging behind the viewRedisAdvisor gate and document the decision.
5. Later: revisit when it reaches 1.0 or when JSON schema is documented — that is the point to integrate with existing alerting/observability tooling.

Operational Impact

Maintenance

• Low carrying cost: one dependency, no runtime component, no schema, no daemon. Upgrade effort is bounded by the pre-1.0 API churn risk — budget a review per minor release, and pin.
• Single-package dependency on a young project is the main maintenance risk; have an exit path (the advisor is diagnostic only, so removal is trivial).

Support

• New artifacts for the on-call runbook: what a skipped check means per provider, what each failing check implies, and how --fail-on failures should be triaged.
• Support burden shifts from "why is Redis slow" reactive debugging to a pre-emptive checklist, which is net-positive but requires someone to own the findings.
• The /redis-advisor route needs an explicit ownership and access-control statement, plus a documented "disable in production" default.

Scaling

• Runtime scales with keyspace size for the key-oriented checks; schedule production runs off-peak and prefer CI/staging runs for routine gating.
• On large instances, consider running against a representative replica or scoping by database index rather than the full keyspace.
• Upstash and similar serverless providers may meter or throttle command volume — confirm SCAN cost before scheduling recurring production runs.

Failure modes

• Skipped checks interpreted as healthy — highest real risk. Skipped ≠ passed; output must be read explicitly, and CI gates must only target checks known to be available on the target provider.
• Connection or ACL denial — should surface as a clear error/skip, not a partial green report.
• CONFIG-disabled providers — persistence and eviction-policy verification go unchecked; cover those manually in the platform review cadence.
• SCAN on a large keyspace — latency spike or timeout; mitigate with off-peak scheduling and bounded runs.
• Route exposure — gate misconfiguration or a wrong APP_ENV could expose operational data; disable the route in production by config, not by convention.
• Pre-1.0 breaking change — an unpinned upgrade could break CI gates or alerting silently; pin and review upgrades.

Ramp-up

• Minimal for engineers: one artisan command, human-readable text output, no new mental model required.
• The learning curve is in interpretation, not usage — the team needs to internalize provider-specific skip semantics and what each of the 12 checks implies for remediation.
• Estimate a short enablement session (30–45 min) covering the checks, the skip matrix per provider, and the CI gate policy; then treat the dashboard as self-service.