Auth Caching==Safely Cache User Profiles and Stop Unnecessary Retries for Faster Authenticated Pages and Fewer API Calls

READ: https://www.debug.school/rakeshdevcotocus_468/laravel-microservices-performance-optimization-a-priority-wise-plan-to-speed-up-holidaylandmark-2o9l

Profile-user lookup cache; non-retryable 4xx retries band

============Expected impact:=====================================
Almost har authenticated click faster, repeated auth calls kam
Cache User Profiles and Stop Unnecessary Retries
Reduce Repeated User Lookups and Failed Requests
Speed Up Authenticated Pages with Safe Profile Caching
Reuse User Profile Data and Fix Retry Rules
Make Authenticated Clicks Faster with Fewer API Calls

=========================Prompt============================================
Act as a senior Laravel and authentication performance engineer. Audit only Auth caching (R4) in HolidayLandmark: repeated profile-user lookups and unnecessary retries of upstream 4xx responses.

Enter Plan Mode first. Do not change code, configuration, or caches until I review and explicitly approve your proposed approach.

Read the project’s AGENTS.md and CLAUDE.md. Verify the installed Laravel version and existing Keycloak authentication flow before recommending changes.

Inspect these four areas separately:

1. Repeated profile-user lookups:
   - Trace authenticated requests through middleware, guards, controllers, Livewire components, composers, and API clients.
   - Identify duplicate lookups within one request and repeated lookups across clicks.
   - Separate profile-data retrieval from token validation, account-status checks, and authorization.

2. Safe caching:
   - Evaluate request-scoped memoization first, then short-lived shared caching where safe.
   - Propose the cache store, minimum required fields, TTL, and keys scoped by realm, tenant, and immutable user ID where applicable.
   - Never use cached profile data as a substitute for token validation or required authorization checks.
   - Preserve account suspension, role changes, logout, token expiry, and user isolation.
   - Explain invalidation after profile updates, role changes, account deletion, and other relevant events, including changes made in another service.
   - Do not cache failed responses or expose tokens and credentials.

3. Retry handling:
   - Inspect HTTP clients, retry callbacks, token-refresh logic, and timeout settings.
   - Stop automatic retries for non-retryable 4xx responses such as 400, 403, 404, and 422.
   - Preserve one controlled token refresh and retry for an eligible 401, without loops.
   - Handle 408 and 429 separately where appropriate, respecting Retry-After and bounded backoff.
   - Keep retries bounded for transient connection errors and eligible 5xx responses; avoid retrying unsafe mutations without idempotency.

4. Failure behavior:
   - Preserve existing login redirects, validation messages, permission checks, and error handling.
   - Define behavior when the cache or profile service is unavailable.
   - Prevent stale cached data from granting access to suspended users or outdated permissions.

For every finding, show:

- Affected page and user action.
- Exact file paths and current line numbers.
- Existing code snippet and upstream call sequence.
- Why it adds repeated lookups, retries, or latency.
- Whether the finding is confirmed or needs measurement.
- Recommended approach and exact locations to change.
- Clearly labelled proposed before/after code—do not apply it.
- Risks, cache invalidation requirements, and focused validation steps.
- How to compare upstream call count, cache hits/misses, retry count, and response time before and after.

Include validation for two different users and tenants, profile updates, role changes, suspended accounts, expired tokens, logout, cache expiry, upstream failures, and 401/403/404/422/429 responses.

Treat “removes 1–2 hops from every click” as an estimate to verify against actual request traces, not a guaranteed improvement.

Finish with a prioritized implementation plan. Explain the proposed caching and retry rules clearly enough for me to review and recommend adjustments.

Stop and wait for my approval. After approval, implement only the agreed changes, preserve existing functionality, and report changed files, line numbers, validation results, and measured improvements. Avoid unrelated refactoring.