Queue + worker ==Send Emails, Notifications, and FCM Through Reliable Background Workers for Faster Invites, Role Changes, and Payment Saves

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

Email, notifications aur FCM background mein bhejo
============Expected output========================
Invite, role-change aur payment saves faster; user ko background work ka wait nahi.
Send Emails, Notifications, and FCM in the Background
Speed Up Saves by Moving Notifications to Queues
Reduce User Waiting with Background Jobs
Improve Queue Workers for Faster and Reliable Delivery
Make Invites, Role Changes, and Payment Saves Faster


====================prompt===========================================================
Act as a senior Laravel performance engineer. Audit only queue and worker handling in HolidayLandmark to identify email, notification, and FCM work that slows user requests.

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

Read the project’s AGENTS.md and CLAUDE.md. Verify the installed Laravel version, queue configuration, and deployment architecture before recommending changes.

Inspect these five areas separately:

1. Request-path work: Trace invite, role-change, and payment-save flows. Identify synchronous emails, notifications, FCM calls, and related external requests. Separate work required for a successful response from work safe to run asynchronously.

2. Queue configuration: Inspect each service’s queue connection, jobs, queue tables or Redis configuration, and environment settings. Identify sync connections, missing workers, and jobs dispatched to queues without active consumers. Do not expose credentials.

3. Jobs and notifications: Inspect existing jobs, mailables, notifications, and FCM services. Recommend version-compatible queued handling, safe payloads, appropriate queue names, and dispatch after successful database commits. Preserve tenant context, recipients, permissions, and notification content.

4. Reliability: Inspect retries, backoff, timeouts, retry_after or visibility timeout, failed-job handling, and duplicate delivery risks. Propose idempotency where needed, especially for payment-related events. Preserve payment verification and essential database writes within the correct transactional flow.

5. Worker lifecycle: Inspect Supervisor, systemd, Horizon if installed, and deployment scripts. Recommend workers running as the appropriate service user, sensible concurrency, logging, monitoring, and safe restarts after deployment. Check that workers can access required files and configuration.

For every finding, show:

- Affected page and user action.
- Exact file paths and current line numbers.
- Existing code or configuration snippet.
- Which synchronous operation delays the response and why.
- Whether the issue is confirmed or needs measurement.
- Recommended approach and exact locations to change.
- Clearly labelled proposed before/after code or configuration—do not apply it.
- Risks to existing functionality and focused validation steps.
- How to measure response time, queue wait time, job execution time, failures, and duplicate delivery before and after.

Treat saves returning in under 0.5 seconds as a target to evaluate, not a guaranteed result. Measure user response time separately from background delivery time.

Finish with a prioritized implementation plan, including queue infrastructure, job changes, worker setup, deployment order, rollback, and validation. 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, validation results, and measured improvements. Avoid unrelated refactoring.