Back In Stock Statamic Laravel Package

Technical Evaluation

Basis and confidence: This assessment is derived solely from the v1.0.1 release notes. No repository, composer metadata, documentation, issue tracker, test coverage, or prior assessment was supplied. Treat all architecture claims as inferred and verify before commitment.

Architecture fit

• The package occupies a well-bounded domain niche in a Laravel commerce stack: capturing "notify me when back in stock" requests against a product, then dispatching emails on restock. It is additive to an existing catalogue/order model rather than a replacement for inventory or checkout logic, which keeps blast radius small.
• Evidence of a Laravel-idiomatic shape: package migrations against back_in_stock_items, a Control Panel surface (likely Filament or a custom admin screen), publishable brand assets, and mail-driven delivery. This is a conventional package-service-provider design and should slot into a standard Laravel app without architectural rework.
• It is not a pure read-only utility. It owns a table, writes on customer-submitted forms, sends mail, and hooks the product save path ("sending now starts after the product's save has finished"). That makes it a first-class subsystem with lifecycle coupling to whatever model represents a product — not a drop-in helper.
• Two notification policies are modelled ("Everyone waiting" vs "As many as came back"), which implies the package tracks waiting-list ordering and per-request quantity. That is meaningful domain logic, and its correctness is the whole value proposition.

Integration feasibility

• Low friction mechanically: composer require, run php artisan migrate, publish assets if the panel needs them. The release explicitly instructs php artisan migrate after updating.
• The real integration work is not installation but verification of concurrent behaviour and a decision on queueing, both of which the release notes surface as live concerns.
• Feasible within a normal sprint for a Laravel-competent team, provided a staging environment can reproduce concurrent saves and concurrent form submissions.

Technical risk

• Patch version carries a schema change. v1.0.1 adds a column to back_in_stock_items. Under semver that is a minor at best; published as a patch it is easy to absorb unintentionally via composer update. Highest-priority unknown: is the column nullable or defaulted, and does existing data need backfill? Non-backfilled rows may silently misbehave in exactly the concurrency paths this release was meant to fix.
• The changelog is a bug ledger for v1.0.0. Over-counting notified users, dropped emails during concurrent sends, stale stock baselines, and duplicate sends to the same address were all shipped. Each is a customer-visible correctness defect in the package's core promise. That is not disqualifying — the fixes read as considered — but it establishes that the concurrency model was under-specified at 1.0.0 and may still have edges the changelog does not cover.
• Synchronous send path. "Without a queue, sending now starts after the product's save has finished" is presented as a feature (saves don't block on a send in progress) but it means an admin saving a product can trigger an unbounded fan-out inline. On a popular restock in "Everyone waiting" mode this is a request-latency and mail-provider-throttling hazard. Whether the mailable implements ShouldQueue is the single most important unknown.
• Idempotency and state ordering. "One email per address" is stated as an outcome; it is unverified whether it is enforced by a database unique constraint or application logic. If application-level only, simultaneous submissions can still race. Similarly, it is unclear whether a request is marked as notified before or after a successful send — a crash mid-fan-out could produce either duplicates or silent omissions.
• Retention and PII. "Restock history is kept for a year after the last request for a product is deleted" means email addresses outlive the user's request by design. Whether history stores raw addresses or pseudonymised records is a compliance question (GDPR/CCPA erasure expectations), and it must be answered before rollout to EU/UK traffic.
• Unbounded growth risk if the one-year purge is manual rather than a scheduled command or DB-level cleanup.
• Cosmetic: SVG metadata removal is irrelevant to risk.

Key questions

1. Exact DDL for the new column — nullable, defaulted, indexed, unique? Is a backfill script required or shipped?
2. Is the notification mailable queued (ShouldQueue), chunked, or fully synchronous? Is there a per-save batch cap?
3. Is "one email per address" enforced by a DB unique index or application check? Is send idempotent under retry?
4. Is the request marked notified before or after successful handoff to the mailer?
5. Does history persist raw email addresses? Is the one-year purge automated?
6. Supported matrix: Laravel and PHP versions, Filament version for the Control Panel, DB engines tested (MySQL/Postgres/SQLite).
7. Does it handle product variants/child SKUs, multi-store, multi-currency, and localised email copy?
8. Are there extension points (events, custom channels such as SMS/webhook) or is email the only channel?
9. Test suite and CI posture, particularly any concurrency tests covering the five fixed defects.
10. Was any published migration or config file mutated in place, creating an overwrite conflict on upgrade?

Integration Approach

Stack fit

• Assumes a Laravel application (10/11/12 range to be confirmed) with a conventional product model and a working mail transport. Queue infrastructure (Redis/SQS/database driver) and a scheduler are the two prerequisites that materially change the operating profile.
• Admin surface assumes Filament or an equivalent panel; confirm the installed major version before deploying, since panel plugins are version-sensitive.
• Fits monolith and modular-monolith deployments cleanly. If the storefront runs on separate services with their own product write paths, the "send after product save" hook must be reproduced in each writer, which raises integration cost considerably.

Migration path

1. Pin explicitly (^1.0.1 or exact) rather than floating — do not let a schema-bearing patch arrive as a transitive surprise.
2. Snapshot the back_in_stock_items table in staging with production-like volume.
3. Run php artisan migrate; confirm the new column's nullability and default. Backfill if the semantics require a defined starting value.
4. Diff any previously published migration/config files against the package versions to detect in-place edits that vendor:publish --force would clobber.
5. Decide the queue posture before enabling on production traffic — retrofitting this after launch means changing user-visible latency characteristics.
6. Rebuild caches (config:cache, route:clear, optimize) as with any provider registration change.

Compatibility

• Treat v1.0.1 as a schema-bearing release regardless of its patch number: it needs a deploy step, a rollback plan (the down() likely drops the column and its data), and a note in the runbook.
• Backward compatible at the API level — no removals or deprecations are announced — so application code should not require changes.
• Where the panel is used, verify the panel major version against the package's constraint; the changelog's "one query" optimisation suggests active work in that code path.

Sequencing

1. Week 0 — diligence: answer the ten questions above, chiefly queued-vs-synchronous and PII in history.
2. Staging: migrate a production-shaped snapshot; confirm no data loss and no behavioural regression on existing waiting lists.
3. Concurrency rehearsal: script simultaneous product saves, simultaneous form submissions for the same address, and a restock with a mixed waiting list. Verify counts match the documented semantics — 5 returned, 3 sold, 2 emailed.
4. Mail sandbox: exercise both notification policies end to end, including a confirmation arriving mid-send.
5. Production: deploy in a low-traffic window, migrate, then run a controlled restock on a low-demand product before enabling on high-traffic SKUs.
6. Post-deploy: monitor mail volume, save-endpoint latency, and duplicate-send reports for two weeks.

Operational Impact

Maintenance

• Active, responsive maintenance is evident from a fast correctness release. That is a positive signal, but it also means the package is still stabilising. Assign a named owner and expect to read source, not just changelogs, when diagnosing anomalies.
• Semver discipline is loose (schema change in a patch). Adopt deliberate pinning and review every release note for migration instructions before upgrading.
• The Control Panel dependency ties upgrade cadence to the panel's major releases — a maintenance coupling worth budgeting for.

Support

• Support load will concentrate on notification trust: "I signed up and heard nothing" and "I got two emails." The five fixed defects were precisely these symptoms, so ticket volume should drop from v1.0.0 levels, but expect residual reports while v1.0.0-era data persists.
• The Control Panel's last-restock view is the primary triage tool; ensure front-line support can read a product's waiting list, notified state, and restock history. The single-query optimisation directly improves triage responsiveness on large catalogues.
• The 2-vs-5 arithmetic correction is worth documenting in customer-facing help content, as it changes observable behaviour for merchants who manually adjusted stock during a restock.

Scaling

• Primary scaling risk is the synchronous send path. An "Everyone waiting" restock on a high-demand SKU can fan out to thousands of addresses inside a single save request. Without queueing or chunking this risks request timeouts, worker exhaustion under Octane, and mail-provider throttling — potentially converting one restock into a partial-send incident.
• Waiting-list writes are modest (one row per request); the table scales linearly with customer interest and is not the constraint. The constraint is outbound mail throughput at restock moments, which are inherently spiky.
• The new retention behaviour grows history monotonically for a year. At scale, plan for partitioning or an index on the retention timestamp if the purge is a scheduled delete.
• The removal of an N+1 on the panel list is a genuine improvement for large-catalogue admin performance.

Failure modes

• Partial fan-out: crash or timeout mid-send leaves some customers notified and some not, with ambiguous state. Mitigation requires knowing whether state is committed before or after send.
• Duplicate send: simultaneous form submissions or a retried job produce two emails to one address. The release claims this is fixed; confirm the mechanism is a database constraint rather than a check-then-act.
• Stale baseline: stock changing while nobody is waiting causes a missed rise. Fixed in v1.0.1, but it was a silent, hard-to-detect failure — validate on real data.
• Mail provider outage: unqueued sends fail inline; without retry semantics those customers are lost silently unless the request row remains pending.
• Migration rollback: down-migration drops a column carrying notification state; a rollback after go-live loses waiting-list integrity. Back up before migrating.
• Purge not running: history grows indefinitely and retained addresses widen the privacy exposure surface.
• Orphaned history: products deleted while history is retained by design — verify the Control Panel degrades gracefully.

Ramp-up

• For a Laravel-fluent engineer: roughly one to two days to install, migrate, and validate the happy path; three to five days to build a real concurrency rehearsal and answer the state-ordering questions.
• Most of the effort is not learning the API but internalising the concurrency semantics — the exact meaning of "as many as came back", the ordering of the waiting list, and when a request transitions to notified. Those must be read from source and encoded as an executable test suite owned by your team.
• Non-Laravel staff (support, merchandising, ops) need only the Control Panel and a one-page explanation of the two notification policies; that is a short, documentable ramp.
• Recommend a written runbook covering: upgrade procedure with migration check, mail-storm contingency for flagship restocks, and the PII retention stance before the first European customer signs up.