Laravel Cachable Attributes Laravel Package

Technical Evaluation

Architecture Fit

• Use Case Alignment: Ideal for Laravel applications where expensive computed attributes (e.g., aggregations, external API calls, or complex calculations) are accessed frequently but rarely change. Reduces database load and improves performance for read-heavy operations.
• Design Pattern: Leverages Laravel’s accessors and caching layer (via Cache facade) to decouple computation from storage. Follows the Flyweight pattern for attribute optimization.
• Modularity: Lightweight (~100 LOC) and self-contained—does not impose global changes to application architecture. Can be adopted incrementally per model.

Integration Feasibility

• Laravel Compatibility: Targets Laravel 8+ (PHP 8.0+). Assumes standard Eloquent model structure. No framework-level hooks or service provider overrides required.
• Cache Backend Agnostic: Works with any PSR-6 cache driver (Redis, Memcached, database, file). Aligns with Laravel’s built-in caching strategies.
• Database Independence: Does not modify schema or require migrations. Purely a runtime optimization layer.

Technical Risk

Key Questions

1. Cache Strategy:

   • Should TTLs be dynamic (e.g., based on model updated_at) or static (e.g., 5 minutes)?
   • How will distributed cache invalidation work in multi-server deployments?

2. Invalidation Granularity:

   • Cache per-attribute or per-model? (Package supports both via cacheKey.)
   • Should invalidation trigger on specific fields (e.g., only price when stock changes)?

3. Observability:

   • How will cache hit/miss ratios be monitored? (Consider adding cache:stats command.)
   • Should failed cache operations log warnings?

4. Fallback Behavior:

   • What happens if the cache driver fails? (Default: recompute attribute.)
   • Should there be a stale-while-revalidate pattern for critical attributes?

5. Scaling:

   • How will this interact with Laravel Horizon or queued jobs? (Avoid race conditions.)
   • Does the app use model events heavily? (Invalidation may add complexity.)

Integration Approach

Stack Fit

• Core Stack: Laravel 8/9/10 + Eloquent. Compatible with:
  • Cache Drivers: Redis (recommended for high throughput), Memcached, database, file.
  • Queues: Database, Redis, or Sync (invalidations should be synchronous for consistency).
  • Testing: PHPUnit (with cache mocking) or Pest.
• Anti-Patterns:
  • Avoid in write-heavy apps (e.g., bulk updates).
  • Not suitable for real-time attributes (e.g., WebSocket updates).

Migration Path

1. Assessment Phase:

   • Profile slowest accessors using Laravel Debugbar or Xdebug.
   • Identify candidate attributes (e.g., fullName, totalOrders, distance).

2. Incremental Adoption:

   • Step 1: Add trait to a single model (e.g., User).

     use Astrotomic\LaravelCachableAttributes\CachableAttributes;
     
     class User extends Model {
         use CachableAttributes;
     }
     

   • Step 2: Mark accessors with cacheable():

     public function getFullNameAttribute(): string
     {
         return cacheable(fn () => $this->first_name . ' ' . $this->last_name, 'full_name');
     }
     

   • Step 3: Implement invalidation in events:

     protected static function booted(): void
     {
         static::saved(fn () => self::clearCachedAttributes());
     }
     

3. Validation:

   • Compare before/after performance (e.g., tntsearch/laravel-profiler).
   • Test edge cases (e.g., concurrent updates, cache failures).

Compatibility

• Laravel Versions: Tested on 8+. For 10+, check for fn() syntax compatibility.
• PHP Extensions: None required beyond standard Laravel stack.
• Third-Party Conflicts:
  • Avoid if using custom accessor modifiers (e.g., appends overrides).
  • Check for conflicts with attribute casting or mutators.

Sequencing

Operational Impact

Maintenance

• Pros:
  • Reduced Database Load: Fewer queries for computed attributes.
  • Simplified Code: Decouples heavy logic from models.
• Cons:
  • Cache Management Overhead:
    • Manual invalidation required (unlike ORM-level caching like remember()).
    • Need to track which attributes are cached in documentation.
  • Debugging Complexity:
    • Stale cache may mask business logic errors.
    • Requires cache-aware logging (e.g., log cache hits/misses).

Support

• Common Issues:
  • Stale Data: Users see outdated values post-update.
  • Cache Spikes: Memory pressure during traffic surges.
• Troubleshooting:
  • Diagnose Stale Data: Check updated_at vs. cache TTL.
  • Monitor Cache: Use cache:forget to test invalidation.
  • Fallback: Ensure attributes work without cache (graceful degradation).

Scaling

• Performance:
  • Best Case: 10–100x faster for cached attributes (e.g., 50ms → 1ms).
  • Worst Case: Cache misses or invalidation storms degrade performance.
• Horizontal Scaling:
  • Distributed Cache: Redis/Memcached required for multi-server setups.
  • Cache Sharding: May need to partition keys by model/attribute.
• Load Testing:
  • Simulate cache stampedes (many requests during TTL expiry).
  • Test invalidations under load (e.g., 1000/s updates).

Failure Modes

Ramp-Up

• Developer Onboarding:
  • Documentation: Add CACHABLE_ATTRIBUTES section to model docs.
  • Training: Show how to:
    • Mark accessors with cacheable().
    • Implement invalidation in events.
    • Debug cache issues.
• Release Strategy:
  • Canary Release: Enable for non-critical models first (e.g., Product).
  • Feature Flag: Wrap trait usage behind a config flag for rollback.
• Metrics to Track:
  • Cache hit rate (`h