Struggling with N+1 Queries Causing Severe Performance Degradation in Laravel Performance Optimization

Introduction & Context:
Our SaaS platform, 'Laravel Quick Fix & Consultation', has recently seen a significant surge in user activity. While this growth is positive, it has exposed critical performance bottlenecks, particularly concerning database interactions. We're now focusing heavily on comprehensive Laravel performance optimization to maintain responsiveness.

Core Problem Statement:
We're consistently encountering N+1 query issues, especially in sections involving complex relationships and nested data structures. This manifests as slow page load times, delayed API responses, and increased server load, directly impacting user experience and operational costs.

Solutions Attempted (and their limitations):

• Eager Loading: We've implemented with() and load() extensively for most direct relationships. However, deeply nested or polymorphic relationships are still proving problematic, leading to N+1 scenarios that are hard to track.
• Database Indexing: All relevant foreign keys and frequently queried columns have been indexed. This provided initial gains but didn't resolve the N+1 fundamental issue.
• Caching Strategy: We're using Redis for caching frequently accessed data and query results. The challenge lies in effective cache invalidation for dynamic content, sometimes leading to stale data or unnecessary cache misses.
• Query Profiling: Tools like Laravel Debugbar and Blackfire have been instrumental in identifying slow queries, but pinpointing the root cause for complex N+1 patterns across multiple models remains a challenge.
• Optimized Controller/Service Logic: We've refactored several areas to reduce redundant database calls and complex computations within controllers and services.

Specific Technical Block & Current Dilemma:
Our primary blocker is effectively identifying and resolving N+1 queries in scenarios involving many-to-many relationships with pivot data, or when using custom scopes that inadvertently trigger lazy loading. We're looking for advanced strategies beyond basic eager loading to handle these intricate cases without over-fetching or creating overly complex query constructs. How do other analytical experts approach deep-dive Laravel performance optimization for such scenarios?

Call for Expert Advice:
We're seeking recommendations on advanced N+1 detection tools, architectural patterns (e.g., repository pattern for complex queries, DTOs), or specific techniques to eliminate these elusive N+1 issues. Are there any common pitfalls we might be overlooking in our Laravel performance optimization efforts? Thanks in advance!