Reference-data caching-(Cache and Reuse Common Lists for Faster Forms and Page Loads with Fewer API and Database Requests)

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

caching	Countries, currencies, languages etc. cache with invalidation

=============Expected impact:=========================
Forms aur repeated page loads faster, API/DB load kam.
Cache Common Lists
Reuse Frequently Used Data
Load Common Lists Faster
Save Lists for Faster Loading
Reduce Repeated Data Requests
=================prompt============================================
Act as a senior Laravel, PHP-FPM, and Apache performance engineer. Audit only concurrency and transport in HolidayLandmark to identify sequential API calls, unnecessary network overhead, PHP-FPM capacity issues, and excessive UI read timeouts.

Enter Plan Mode first. Do not change code, configuration, environment variables, or server processes until I review and explicitly approve your proposed approach. Begin with read-only inspection.

Read the project’s AGENTS.md and CLAUDE.md. Verify the installed Laravel, PHP, Apache, and Keycloak versions, active modules, network topology, and PHP-FPM pool configuration.

Inspect these six areas separately:

1. Http::pool for fan-outs:
   - Identify independent upstream read requests currently executed sequentially.
   - Recommend version-compatible Http::pool usage with bounded concurrency and explicit response mapping.
   - Preserve authentication headers, tenant context, timeouts, error handling, and partial-failure behavior.
   - Keep dependent calls sequential. Do not parallelize mutations without verifying ordering and idempotency.
   - Check downstream capacity and shared FPM pools for worker starvation. Explain that pooling reduces waiting time but does not remove N+1 requests.

2. Internal service base URLs:
   - Trace internal calls that unnecessarily pass through public DNS, TLS termination, redirects, or external routing.
   - Evaluate private service addresses and plain HTTP only where traffic stays within a verified trusted, isolated network.
   - Retain HTTPS where network trust or isolation is insufficient.
   - Preserve service authentication, Host-dependent routing, URL generation, and public browser-facing URLs.

3. KEYCLOAK_INTERNAL_URL for hl-home:
   - Inspect discovery, token exchange, refresh, userinfo, JWKS retrieval, and logout calls.
   - Evaluate a separate internal URL for eligible server-to-server requests.
   - Preserve the public issuer, issuer validation, browser authorization URLs, callback URLs, and logout redirects.
   - Verify Keycloak hostname and proxy settings. Do not blindly replace discovery URLs or disable TLS or issuer validation.

4. PHP-FPM hot pools:
   - Inspect current process manager settings, traffic, worker memory, listen queues, max_children saturation, and available server RAM.
   - Evaluate pm=dynamic against the current configuration using measured workload.
   - Propose pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers, and pm.max_requests where justified.
   - Account for all pools, database connections, and other processes within the total memory budget.
   - Preserve service users, permissions, and isolation. Explain required reloads and rollback.

5. UI read timeouts:
   - Inventory connection timeouts, total timeouts, retries, and cumulative request budgets.
   - Recommend shorter values based on measured upstream latency and acceptable UI response time.
   - Preserve meaningful error messages and safe partial results where supported.
   - Keep payment, upload, and mutation paths outside scope unless reported separately.
   - Avoid retry storms and confirm that pooling does not multiply the effective timeout budget unexpectedly.

6. Later phase: Apache event MPM with HTTP/2:
   - Inspect the current MPM, PHP handler, mod_http2, TLS termination, and proxy configuration.
   - Check compatibility with PHP-FPM and identify migration requirements.
   - Separate this infrastructure migration from immediate fixes.
   - Explain expected benefits, limitations, deployment prerequisites, validation, and rollback. Do not assume HTTP/2 improves internal API execution time.

For every finding, show:

- Affected service, page, and user action.
- Exact file paths and current line numbers.
- Existing code or configuration snippet.
- Current call sequence or transport path.
- Evidence of latency, worker contention, or unnecessary overhead.
- Whether the issue is confirmed or needs measurement.
- Clearly labelled proposed before/after code, configuration, or commands—do not apply them.
- Risks, prerequisites, focused validation, and rollback steps.

Propose comparable before/after measurements for response time, upstream duration, request count, failures, CPU/RAM, FPM active/idle workers, listen queues, and downstream load. Evaluate both individual requests and realistic concurrent traffic in an approved test environment. Do not invent improvement percentages.

Finish with a prioritized implementation plan separating immediate application changes, network/FPM changes, and the later Apache HTTP/2 migration. Explain the proposed fixes 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, executed commands, validation results, and measured improvements. Avoid unrelated refactoring.