At a glance
- Client: a popular pizza delivery service running a software platform it planned, developed and continues to improve in house
- What the system does: accepts orders online via site and mobile app, integrates counters and transactions, queues orders for the bakers, coordinates couriers, manages deliveries and analyses sales
- Trigger: the client needed a system performance evaluation ahead of a regional marketing campaign
- Second task: investigate the possibilities of distributing the system load through the year rather than only surviving peaks
- Primary load emulated: site and mobile app users, plus the cashiers taking orders at the counter
- Secondary load emulated: the tracker controlling order execution, the in-store TV boards requesting information from the system, and the information screens
- The hardest constraint: 2–3 releases per day, so scripts had to be updated continuously because any update could change the system's processes
- Delivered: confirmed performance against the load criteria, a named list of bottlenecks with strategies, the critical areas to monitor in production, and optimisation proposals with implementation advice
Every order touches half the company
The platform is not a website with a shopping cart attached. It accepts orders through the web interface and mobile apps, accepts branch orders from call-centre employees and shift managers, accounts for the quality and speed of order execution, coordinates couriers and analyses sales - and it performs dozens of operations simultaneously that no person would keep in their head at once.
That is exactly the kind of system where a marketing campaign is dangerous. The campaign does not simply add web traffic; it adds web traffic *and* counter traffic *and* tracker events *and* courier coordination *and* the screens in every pizzeria asking the system for updates, all at the same time of day. The client employed PFLB to test the system and tune its performance before finding out the hard way.
Two questions were on the table: how much more load can the platform take from the app, the site, the couriers and the restaurant counters - and can that load be spread across the year rather than concentrated where the business happens to put it.
How the load was reproduced
The system holds several applications covering distinct business processes: accepting customer orders through web and mobile; accepting restaurant branch orders from call-centre employees and shift managers; and accounting for the quality and speed of order execution.
The test reproduced that structure rather than averaging it:
- Most of the load came from site and mobile app users and from the cashiers taking orders - the paths that carry the money.
- Secondary load sources emulated the system's own workflow: the tracker controlling order execution, the TV boards in the pizzerias requesting information, and the information screens. These influence the business processes even though no customer touches them.
- Test cases were written to contain the script and emulator run schedule, alongside scripts emulating user actions, which retrieved the number of current operations, their intensity and the number of virtual users performing them, and recorded test duration.
- Monitoring used the client's own stack - Grafana plus an InfluxDB solution, with Telegraf on Windows and exporters on \*nix - rather than a parallel observability setup built for the test and thrown away afterwards.
Based on the results the team analysed the system's load criteria at different load levels, including beyond maximum performance, which is where the useful information lives: the ordering of failures tells you what to fix first.
What made this project difficult
- No routine for load testing existed. The company had a startup workflow with no place for load testing in it, and much of the time was lost configuring the load testing environment before any measurement could start.
- There was no recent service specification. The team had to learn the system on the fly, from the system itself.
- Releases landed 2–3 times a day. Scripts required constant updating, because every update could change the system's processes and silently invalidate a test.
None of these is a technical obstacle in the usual sense, and together they consumed more of the project than the testing did. They are also the normal condition of a fast-moving product company, which is why they are worth stating plainly rather than omitting.
Results
- System performance was recorded against the load criteria and found to satisfy them.
- Bottlenecks were named, along with the possible strategies to overcome them.
- The factors that decrease performance were classified: lack of hardware or system resources, and the limits of the software architecture - two categories with completely different remedies.
- The critical areas requiring monitoring in production were listed, so the client's existing Grafana and InfluxDB setup could watch the right things.
- The most resource-hungry and longest operations were selected for optimisation, and PFLB advised on implementing the proposals rather than handing over a report.
Questions this engagement answers
What should a load test of an ordering platform actually emulate?
Not just customers. Here the profile included site and app users, counter cashiers, the order tracker, the in-store TV boards and the information screens - because during a campaign all of them get busier together.
Is it worth load testing a system that releases 2–3 times a day?
Yes, but the cost of script maintenance has to be planned for from the start. On this project every release could change the system's processes, and keeping scripts current was a continuous task rather than a setup step.
What do you get when there is no up-to-date specification?
The testing itself becomes the discovery. The team learned the service on the fly, and one of the deliverables - the list of critical areas to monitor in production - is essentially documentation the client did not previously have.
"Add hardware" or "change the architecture"?
The analysis separated those two: some performance loss came from missing hardware or system resources, some from limits in the software architecture. Buying servers only helps the first category, which is why the distinction is the deliverable.
Campaign booked before the capacity is known?
A marketing date is a load event you can see coming. The useful output is not a pass mark but a ranked list - which operations are heaviest, which limits are hardware and which are architectural, and what to watch in production once the traffic arrives.
