Normalizer Extension Bundle Laravel Package

Product Decisions This Supports

• Per-batch caching policy as a product lever. AbstractBatch::CACHE_LIFETIME now lets each batch declare its own cache posture, with NULL explicitly meaning "no cache." That turns caching from an implicit, package-wide behavior into a deliberate decision per workload — useful when some jobs must be strongly consistent (billing, inventory, entitlements) and others can tolerate staleness (dashboards, exports, digest emails).
• Feature/roadmap framing. Teams can now ship performance improvements to heavy batch jobs without touching jobs that need fresh reads, rather than making a global trade-off. This is the kind of knob that unblocks "make exports faster" tickets that would otherwise stall on correctness concerns.
• Build vs. buy. If your product already runs multi-step jobs on Laravel queues, this replaces a stack of bespoke cache-key and invalidation logic with a single declarative constant. Weigh it against custom scheduling code and against dedicated orchestration (Horizon, a workflow engine) if batch complexity is a core differentiator.
• Concrete use cases: nightly report generation, CSV/data exports, third-party sync and backfill jobs, notification fan-out, search indexing — anywhere the same expensive read is repeated across a batch.
• Risk decision to make explicitly: the NULL semantics are the interesting part. Confirm whether this is a behavior change from prior versions. If NULL previously fell back to a default cache lifetime, this release silently disables caching for existing batches — a correctness improvement but a performance regression for anyone relying on the old default.

When to Consider This Package

Adopt when:

• You run recurring or multi-step batch workloads on Laravel and want caching to be a per-batch configuration decision rather than global infrastructure.
• You value a small, legible surface area over a full orchestration platform.
• Your consistency requirements vary by job, and you want a single obvious place to express "this one must never serve stale data."

Look elsewhere when:

• You need durable, distributed batch orchestration with retries, fan-out/fan-in, and observability — reach for Horizon plus purpose-built job pipelines, or a dedicated workflow engine.
• You require exactly-once or transactional guarantees across batch steps; a cache lifetime constant does not address that.
• Caching is core to your product and you need tagged caches, per-key TTLs, stampede protection, or warm-on-deploy strategies beyond a single lifetime value.
• You are not on Laravel/PHP, or you are on a version of the framework the package does not support.

Before adopting, verify: the exact NULL behavior relative to the version you are on, whether a non-NULL lifetime accepts sub-second or DateInterval values, and how cache keys are namespaced across batch instances (relevant if two batches share a payload shape).

How to Pitch It (Stakeholders)

For executives: This release makes caching an explicit, per-job setting instead of a package-wide default, with an off switch for anything that must read fresh data. The business value is lower compute cost and faster batch runs on the jobs where staleness is acceptable, without exposing money- or inventory-sensitive workflows to stale reads. Integration cost is low: one constant per batch, no new infrastructure. The main thing to approve is a short verification pass to confirm no existing job silently loses caching under the new NULL behavior.

For engineering: CACHE_LIFETIME = NULL now means "do not cache." This is a cleaner mental model than an implicit default and puts cache policy next to the batch it affects, which should cut down on cross-service confusion about why a job served old data. Two things to check in review: audit existing batches for reliance on the previous default, and confirm cache key scoping so two batches with identical inputs do not collide. If we adopt, treat the constant as a documented contract — a NULL should be a reviewed decision, not an accident — and add a test that asserts the no-cache path for any batch handling financial or inventory data.