Building Web Apps with Laravel Module 14
Caching and performance interview questions
Interview questions on caching and performance: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher
The centre dashboard is cached for 10 minutes. A parent pays a fee at the desk. When does the manager see the payment, and how do you make it appear at once?
Answered in the lesson Caching data, responses and the framework
-
Fresher to mid
Why does a cached object come back as __PHP_Incomplete_Class in Laravel 13?
Answered in the lesson Caching data, responses and the framework
-
Fresher
What do private, no-store and no-cache tell a cache in a Cache-Control header?
Answered in the lesson Caching data, responses and the framework
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Mid to senior
A reports endpoint caches an expensive aggregate with Cache::remember() for one hour. Every hour, on the hour, database CPU jumps to 100 % for about a minute and some requests time out. How do you confirm the cause, and fix it without making the report any less fresh?
- What it tests
- Recognising a stampede from its timing, proving it with rebuild counts per key, and choosing between a rebuild lock, stale-while-revalidate and precomputing, including the cold start that each choice leaves open.
- First step
- Line the spike up with the entry's expiry. If it starts within a second of it, count how many requests ran the aggregate in that minute, from the slow-query log or a counter around the closure. Dozens of identical aggregates at once mean every request that missed rebuilt the value itself.
- Follow-ups
-
- Would you use a lock, flexible(), or both, and why?
- What happens on the first request after a deploy or a restart of Redis?
- How would you prove that only one rebuild runs?
- The aggregate grows to 40 seconds. What changes?
From the lesson Caching data, responses and the framework
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Mid to staff
A CDN was put in front of Pathshala's Laravel app. A day later a guardian reports seeing another family's fee page. No application code changed. What do you check first, how do you stop it today, and how do you keep it from happening again?
- What it tests
- Treating Cache-Control as the contract with shared caches, spotting public or overridden directives and cached Set-Cookie headers, containing a data exposure, and adding tests and defaults that keep personal pages private.
- First step
- Contain it before diagnosing: switch the CDN to pass signed-in traffic straight to the origin, and purge its cache. Then request the fee page as a test guardian twice, once through the CDN and once from the origin, and compare Cache-Control, Set-Cookie and the CDN's own hit or miss header.
- Follow-ups
-
- Which header values would point at the application, and which at the CDN's settings?
- Could the guardian have been signed in as the other family, and what follows if so?
- How do you find every other page that can leak in the same way?
- What stops a personal route from being made cacheable again next year?
From the lesson Caching data, responses and the framework
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Mid to senior
After a release, the fee dashboard of Pathshala's largest centres went from about 300 ms to 1.4 s at the 95th percentile, while small centres look unchanged and no errors are logged. How do you find the cause, fix it and make sure it cannot come back unnoticed?
- What it tests
- Measuring before guessing, reading a cost that grows with the data, choosing the cheapest fix, and a guard that catches the regression in the build and in production numbers.
- First step
- Measure the same page for a small and a large centre, with the query count and time of each request. If the count grows with the centre's size, the release added queries per row; compare the two counts with the commit that changed the page.
- Follow-ups
-
- Why did the small centres look unchanged?
- How would you fix it, and how do you prove the fix?
- What test keeps it fixed, and what data does that test need?
- Which production number would you watch, and with what limit?
From the lesson Profiling and optimizing a Laravel app
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Senior to staff
After the PHP settings of the web servers were tuned for speed, some deploys seem to have no effect: the new code is on disk, the queue workers run it, but web visitors keep getting the old behaviour until someone restarts the servers. What is going on, and how should deploys work from now on?
- What it tests
- Knowing how PHP keeps compiled code between requests, which settings stop it from checking files, what each restart or reload covers, and how to verify which release is serving.
- First step
- Prove what each part runs before changing anything: add a response header or a small page that prints the release, and request it from every web server and after every deploy step. Then compare the PHP settings of the web servers with the ones they had before the tuning.
- Follow-ups
-
- Why do the queue workers run the new code while the web servers do not?
- Which deploy step fixes it, and in which order?
- Would you keep the setting that caused it?
- How would you notice a server that serves an old release?
From the lesson Profiling and optimizing a Laravel app
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
You join a team whose Laravel application feels slow. There is no monitoring, only a week of web server access logs and the code. How do you decide what to optimise first, and how will you show the team that it worked?
- What it tests
- Turning logs into per-route numbers, telling server-time cost from user waiting, choosing fixes in the right order, and setting up measurement that outlasts the first fix.
- First step
- Turn the logs into numbers per route before reading any code: requests, median and 95th percentile time, and the total time each route cost. Check first that the log format records the request time at all; without it the logs only count requests.
- Follow-ups
-
- Which route do you pick when the busiest one and the slowest one differ?
- What do you measure on that route before changing it?
- Which monitoring would you add, and where would its dashboard live?
- How do you report the result without overstating it?
From the lesson Profiling and optimizing a Laravel app
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Mid to senior
Pathshala's portal moved from PHP-FPM to Octane on FrankenPHP. Since then some parents get pages in English although their browsers ask for Hindi, and each worker's memory climbs through the day until it restarts. The tests pass and nothing else changed. How do you find the causes and fix them?
- What it tests
- Knowing what an Octane worker keeps between requests, reproducing a leak on purpose, fixing it at its source and guarding against the next one.
- First step
- Reproduce it outside production before changing any code: serve two requests in a row from one booted application, differing only in Accept-Language, then a thousand requests while logging memory_get_usage() after each. Which request goes wrong first, and how much memory each request adds, tell you where to look.
- Follow-ups
-
- Why did the test suite catch neither problem?
- Some pages show the right guardian's name in the wrong language. What does that tell you?
- How do the fixes for the language and for the memory differ?
- How would you keep such leaks out of later releases?
From the lesson Octane, FrankenPHP and concurrency
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Senior to staff
A team wants to move a Laravel API to Octane because it read that Octane makes Laravel several times faster. The slowest endpoints spend about 300 ms in the database, the fastest take about 8 ms in all, and the servers reach 70 % CPU at peak. How do you decide, and what do you measure first?
- What it tests
- Separating the fixed boot cost from query and wait time, estimating the gain per endpoint from measurements, and weighing it against the work and risk that Octane adds.
- First step
- Measure the CPU time per request of a route that does almost nothing and of each busy endpoint, under the current PHP-FPM setup with OPcache on. The trivial route's cost is roughly the boot that Octane can remove; its share of each endpoint, weighted by that endpoint's traffic, is the most the switch can save.
- Follow-ups
-
- What does Octane change for the 300 ms endpoints?
- How much capacity could the 8 ms endpoints gain?
- What work does the switch add for the team?
- What would make you say no?
From the lesson Octane, FrankenPHP and concurrency
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A report page calls three independent services one after another, about 0.6 s each. A developer wraps the calls in Concurrency::run(), and on a laptop the page drops to about 0.8 s. Under real traffic the servers then run short of memory and of PHP processes. What happened, and what would you do instead?
- What it tests
- Knowing how the process driver runs closures, what each call costs, how that multiplies under concurrent requests, and the other ways to overlap slow calls.
- First step
- Count the processes. Each Concurrency::run() call starts one PHP process per task, and each of them boots the framework, so 50 report requests at once mean 150 extra PHP processes beside the web workers. Measure an empty task's start-up on the server and the peak number of PHP processes during traffic.
- Follow-ups
-
- Why was it fast on the laptop?
- Why not switch to the fork driver?
- What can send three HTTP calls at once without new processes?
- When is Concurrency::run() the right tool?
From the lesson Octane, FrankenPHP and concurrency
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
All Building Web Apps with Laravel interview questions · The Building Web Apps with Laravel track