Laravel Microservices Performance Optimization: A Priority-Wise Plan to Speed Up HolidayLandmark

Why Does the Application Become Slow?
WH Questions: Understanding the Improvement Plan
Priority-Wise Improvement Overview
P1 — Server Tuning(Speed Up Livewire Forms, Modals, and Lists with Fewer Requests, Targeted Updates, and Smaller Payloads)
P2 — Authentication Caching(Safely Cache User Profiles and Stop Unnecessary Retries for Faster Authenticated Pages and Fewer API Call)
P3 — Remove HTTP N+1 Requests(Batch Per-Row API Requests and Remove Repeated or Unused Calls for Faster Lists and Dashboards)
P4 — Queue and Worker (Send Emails, Notifications, and FCM Through Reliable Background Workers for Faster Invites, Role Changes, and Payment Saves)
P5 — Livewire Hygiene (Speed Up Livewire Forms, Modals, and Lists with Fewer Requests, Targeted Updates, and Smaller Payloads)
P6 — Reference-Data Caching (Cache and Reuse Common Lists for Faster Forms and Page Loads with Fewer API and Database Requests)
P7 — Image Pipeline (Reduce Image Size and Speed Up Previews, Uploads, and Page Loading with Caching)
P8 — Concurrency and Transport
P9 — Growth Hygiene
Measure Before and After Every Change
Recommended Implementation Order

A slow application does not always need a complete rewrite. Performance often suffers because each click repeats authentication lookups, makes unnecessary API calls, reloads entire lists, or waits for notifications to finish.

HolidayLandmark’s improvement plan addresses these problems step by step while preserving existing functionality. The priority is to improve areas that affect the whole application first, followed by individual workflows.

The proposed 40–70% improvement and saves under 0.5 seconds are targets to verify through measurement, not guaranteed outcomes.

1. Why Does the Application Become Slow?

1.1 Repeated Startup Work

Every service request spends time loading PHP code, configuration, and routes. When a user action calls several services, this overhead accumulates.

1.2 Repeated Authentication Calls

The same user profile may be fetched repeatedly during authenticated interactions, increasing API traffic and response time.

1.3 HTTP N+1 Requests

A list makes an additional API request for each row. As the number of records increases, the number of requests also grows.

1.4 Background Work During Saves

Email, notifications, and FCM delivery keep users waiting when they run inside the save request.

1.5 Unnecessary Livewire Requests

Typing, opening modals, and closing drawers can trigger server requests even when the action only changes the interface.

1.6 Repeated Reference-Data Fetching

Forms repeatedly request countries, currencies, languages, and other data that rarely changes.

1.7 Heavy Image Processing

Large images increase browser memory usage, upload time, and server processing.

1.8 Sequential Service Calls

Independent API requests run one after another, making users wait for their combined execution time.

1.9 Database Growth

Missing indexes, inefficient filters, and connection pressure become more noticeable as data and usage increase.

2. WH Questions: Understanding the Improvement Plan

3. Priority-Wise Improvement Overview

4. P1 — Server Tuning

What Is the Problem?

Every request pays the cost of PHP execution and Laravel startup.

Why Is This the First Priority?

Reducing startup overhead can benefit many pages and service calls at once.

Solutions

• Size OPcache according to actual usage and available memory.
• Audit env() calls outside config/ before enabling configuration caching.
• Run config:cache and route:cache for each compatible service.
• Use the project’s specified deployment user, hl_platform.
• Verify that PHP-FPM can read the generated cache files.
• Add cache rebuilding to each holiday-new/*/pull.sh after ownership is corrected.
• Rebuild configuration cache after .env changes.
• Set LOG_LEVEL=warning where appropriate while retaining required operational and audit records.

============Expected Impact=======================

Speed Up Every Request with Better Server Settings
Improve Application Speed with OPcache and Laravel Caching
Reduce Request Overhead with Caching and Smarter Logging
Tune Server Settings for Faster Pages
Optimize OPcache, Deployment Caches, and Log Levels

Laravel configuration caching changes how environment values are loaded. Application code should read these values through configuration rather than depending on direct .env lookups outside configuration files.

When Should It Be Done?

After auditing environment usage, route-cache compatibility, and deployment permissions.

Who Should Handle It?

DevOps and backend developers.

Where Should It Apply?

Relevant PHP-FPM configuration, Laravel services, and deployment scripts.

Expected Benefit

Lower startup overhead across service requests.

5. P2 — Authentication Caching

What Is the Problem?

Authenticated clicks may repeatedly fetch the same user profile. Retrying permanent upstream failures adds further delay.

Why Does It Matter?

Authentication-related overhead affects many actions performed by logged-in users.

Solutions

• Reuse profile data within a request.
• Add a short-lived cache for suitable profile fields across requests.
• Separate cache keys by user and relevant tenant or realm.
• Invalidate cached data when profiles change.
• Keep security-sensitive authorization decisions appropriately fresh.
• Stop retrying non-retryable 4xx responses.
• Handle token refresh and rate limits separately.

When Should It Be Done?

After tracing the existing authentication flow and identifying duplicate lookups.

Who Should Handle It?

Backend developers responsible for authentication and API clients.

Where Should It Apply?

Authentication middleware, guards, profile-service clients, and related request flows.

Expected Benefit

Fewer profile-service calls and faster authenticated interactions.

6. P3 — Remove HTTP N+1 Requests

What Is the Problem?

A page with 50 records may generate 50 additional requests if every row performs its own lookup.

Why Does It Matter?

The number of API calls grows with the number of records, making larger lists increasingly slow.

Solutions

• Batch tourist contact lookups.
• Batch organizer metrics.
• Fetch team-member user details together.
• Remove unused booking getByPublicRef calls.
• Deduplicate IDs before requesting related records.

When Should It Be Done?

When request tracing shows per-row API calls or unused requests.

Who Should Handle It?

Backend developers responsible for list pages and service endpoints.

Where Should It Apply?

Tourist lists, organizer dashboards, team management, and booking workflows.

Expected Benefit

Major improvement in lists and dashboards, especially as record counts grow.

7. P4 — Queue and Worker

What Is the Problem?

Users wait unnecessarily when saves also perform email, notification, and FCM delivery.

Why Does It Matter?

External delivery services can be slow or temporarily unavailable, extending the save request.

Solutions

• Configure a real asynchronous queue.
• Run a supervised queue worker.
• Queue email, notification delivery, and FCM tasks.
• Dispatch jobs after the relevant database transaction commits.
• Add retries and failed-job monitoring.
• Protect against duplicate delivery.
• Keep payment validation and essential database updates in the request.
• Queue payment-related follow-up work.

When Should It Be Done?

After identifying delivery tasks that can safely run asynchronously.

Who Should Handle It?

Backend developers and DevOps.

Where Should It Apply?

Invite, role-change, notification, and payment-related workflows.

Expected Benefit

Faster saves. Measure whether the proposed under-0.5-second target is achievable.

8. P5 — Livewire Hygiene

What Is the Problem?

Small interface actions can generate unnecessary requests or reload more data than needed.

Why Does It Matter?

Frequent interactions make this overhead noticeable throughout everyday use.

Solutions

• Open and close purely visual modals using Alpine.
• Replace unnecessary live updates with deferred or blur-based binding.
• Use binding syntax compatible with the installed Livewire version.
• Scope NavbarComposer to the header.
• Update the affected row after a save instead of reloading the entire list.
• Reduce large public array properties and response payloads.

When Should It Be Done?

After identifying requests that only change visual state or unnecessarily reload data.

Who Should Handle It?

Frontend and backend developers working on Livewire components.

Where Should It Apply?

Forms, modals, drawers, navigation, and list components.

Expected Benefit

Faster typing, modal interactions, and saves.

9. P6 — Reference-Data Caching

What Is the Problem?

Forms repeatedly fetch lists that change infrequently.

Why Does It Matter?

Repeated requests increase page-load time and API or database load.

Solutions

• Cache countries, currencies, and languages.
• Cache statuses, verification levels, and organizer categories.
• Invalidate affected keys after successful updates.
• Use Redis for shared caching across services.
• Include language, tenant, or other context in cache keys where necessary.
• Set expiry periods as a fallback for missed invalidation.

When Should It Be Done?

After defining cache keys, update paths, and invalidation rules.

Who Should Handle It?

Backend developers, with DevOps support for Redis.

Where Should It Apply?

Shared reference-data services and forms that consume those lists.

Expected Benefit

Faster forms and repeated page loads, with fewer API and database requests.

10. P7 — Image Pipeline

What Is the Problem?

Large images increase upload time and processing load. Recreating previews can also repeat browser work.

Why Does It Matter?

Image-heavy workflows can remain slow even after other page interactions improve.

Solutions

• Resize suitable images in the browser.
• Use stable createObjectURL previews.
• Revoke object URLs when they are no longer needed.
• Stream uploads to the file service.
• Use bounded concurrency for multiple uploads.
• Disable the save button while saving.
• Apply long-lived immutable caching only to public assets with versioned or unique URLs.
• Later, introduce signed direct uploads and queued WebP variants.

When Should It Be Done?

After measuring image sizes, upload duration, and preview behavior.

Who Should Handle It?

Frontend developers and backend developers responsible for the file service.

Where Should It Apply?

Image forms, upload components, file-service endpoints, and public asset responses.

Expected Benefit

Faster previews and uploads, with fewer duplicate submissions.

11. P8 — Concurrency and Transport

What Is the Problem?

Independent calls take longer when executed sequentially. Slow upstream services can also hold interface requests open.

Why Does It Matter?

A page that calls several services can accumulate substantial waiting time.

Solutions

• Use Http::pool for independent fan-out requests.
• Set shorter, workflow-appropriate timeouts for UI reads.
• Configure KEYCLOAK_INTERNAL_URL for hl-home where supported.
• Consider internal HTTP only within a trusted, isolated network.
• Retain appropriate protection for sensitive traffic.
• Evaluate pm=dynamic using traffic and memory measurements.
• Later, assess Apache event MPM and HTTP/2 compatibility.

When Should It Be Done?

After identifying independent calls and checking infrastructure compatibility.

Who Should Handle It?

Backend developers and DevOps.

Where Should It Apply?

Service clients, internal networking, Keycloak integration, PHP-FPM, and Apache.

Expected Benefit

Lower aggregate waiting time for pages that call several services.

12. P9 — Growth Hygiene

What Is the Problem?

Inefficient queries and connection pressure become more expensive as data and traffic grow.

Why Does It Matter?

An application that works well with small datasets may slow down significantly with larger ones.

Solutions

• Evaluate PgBouncer against the application’s connection and transaction behavior.
• Add missing foreign-key indexes where query patterns justify them.
• Replace suitable whereDate filters with timestamp ranges.
• Paginate or limit unbounded queries.

When Should It Be Done?

When query plans, connection metrics, or growing datasets show a need.

Who Should Handle It?

Backend developers and the database or infrastructure team.

Where Should It Apply?

PostgreSQL, database connection configuration, and query code.

Expected Benefit

More predictable database response times as usage increases.

13. Measure Before and After Every Change

Measurement starts before P1 and continues throughout implementation.

Verification Process

1. Record the current performance of representative actions.
2. Implement one improvement.
3. Repeat the same actions with comparable data and conditions.
4. Compare typical response times, slow responses, request counts, and errors.
5. Verify that existing functionality still works.
6. Continue to the next priority when the results are acceptable.

14. Recommended Implementation Order

Follow this order initially, then adjust later priorities if measurements identify a stronger bottleneck.

The goal is to reduce unnecessary work, improve response times, and preserve existing functionality through small, measurable changes.

Reference

• Laravel Deployment Documentation — consult the documentation matching the project’s installed Laravel version.