How a leading automation and load testing engineer reduces incidents by 25% and keeps systems stable during peak hours
In 2025, the cost of IT errors has reached a critical level. According to Uptime Institute, the share of failures due to procedural mistakes increased by 10 percentage points, while Splunk estimates total losses for Global 2000 companies at $400 billion annually. More than half of these incidents are caused by human error, and traditional testing methods struggle to keep up with rising workloads.
Russian engineer Roman Kirillov is turning load testing into a strategic “insurance” for businesses. With experience in fintech (WalletOne), gaming (TvBet), and HoReCa (Lemma-Group), he implements Gatling and optimizes CI/CD pipelines, reducing incidents by 25% and speeding up release processes. His solutions allow systems to handle millions of transactions and thousands of orders during peak hours. Roman also created a Gatling course, published in professional outlets, and serves as a judge at international competitions, including the Technology & Design Awards.In addition, he was recently accepted as a member of the International Software Quality Association (ISQA), further cementing his recognition as a global expert in automation and load testing.
He shared with us how automation and load testing have become strategic tools to protect businesses, why choosing the right tool is critical for scalability, and how his approach helps HoReCa systems run smoothly even during the busiest hours.
Roman, you recently worked on load testing restaurant systems running on iiko. What were the main challenges you faced when dealing with thousands of orders during peak hours?
In recent projects, scale and speed were the key challenges. We had to model peak scenarios — orders, payments, supplier synchronization — while simultaneously addressing infrastructure scalability. Gatling allowed us to create realistic scenarios that revealed backend bottlenecks, such as slow database queries. We also implemented CI/CD pipelines combined with Prometheus monitoring. This reduced incidents by roughly 25% and enabled us to detect problems before release. Equally important was coordinating a team of six engineers and training colleagues in load testing, ensuring the team was ready to handle sudden spikes.
You implemented Gatling as a load testing tool in real HoReCa projects. Why was it the most suitable tool for the restaurant industry?
We compared several options: JMeter, K6, The Grinder, and Locust. JMeter is simple, but its “one user equals one thread” model does not scale well. K6 is modern, but at that time its ecosystem was limited. Gatling stood out due to its asynchronous architecture on Akka, which efficiently handles thousands of virtual users, its Java DSL, which allowed us to reuse libraries and integrate with CI/CD, and its detailed reporting, which made it easy to analyze and optimize bottlenecks. In the restaurant industry, where delays directly translate into lost orders, those advantages weren’t just technical — they were critical for business survival.
Your experience spans not only the restaurant market but also fintech and gaming. Are there any unique “pains” in HoReCa that distinguish it from other industries?
HoReCa is uniquely sensitive to peak hours. Thousands of orders can arrive in just 10–20 minutes. In fintech, load is often more evenly distributed, and in gaming, peaks align with releases, but in restaurants, delays mean an immediate loss of customers. HoReCa also heavily depends on supplier integrations and local infrastructure, creating multiple points of failure. Peak synchronization, combined with the direct impact on reputation, makes these challenges particularly demanding.
In one project, load testing helped prevent failures during mass orders. Can you explain how this worked in practice?
We had a B2B platform for registering support requests from restaurants. During update periods, load reached 10,000 requests per hour, causing the system to slow down and even lose data. We replicated scenarios with different request priorities in Gatling and identified the bottleneck: parallel database writes. I proposed splitting services and partially moving to a non-SQL solution. Processing time dropped by about 40%. During the next peak, the system handled 12,000 requests per hour without data loss, keeping business operations safe.
Often, businesses see testing as a cost rather than an investment. How did you convince management and clients that load testing is truly “insurance” for the business?
I present figures and loss scenarios: a single critical failure during a peak hour can cost a restaurant a month’s revenue. We justified the need for a dedicated test environment and tools. After implementing Gatling and Allure reporting, incidents fell by 25%, and the environment paid for itself in just a couple of months. In WalletOne and TvBet, Allure TestOps provided transparent reports for the business. It became clear that testing was not just a QA task but a risk management instrument.
You worked with CRM, payment, and delivery integrations in iiko. How does load testing help these systems work synchronously without failures?
Automation checks business logic and integration correctness — ensuring transactions are accurate and CRM data aligns — while load testing stresses these real-time interactions. In WalletOne, we tested synchronization with tax authorities and government services; in TvBet, we simulated peak player flows; currently, we’ve tested up to 12,000 requests per hour. The combination of automated tests and load scenarios helps identify and eliminate bottlenecks at the system interfaces before going live.
Your Gatling course became a significant contribution to the QA community. How did your experience influence the course content?
The course is built on real-world cases, focusing on optimizing asynchronous scenarios, integrating monitoring and CI/CD, and analyzing metrics and reports. My experience mentoring teams inspired me to develop modules on knowledge transfer and results analysis. The course is practical, with a focus on solving real bottlenecks rather than theory.
In gaming projects, such as TvBet, you reduced regression testing from four days to two or three hours. Can similar acceleration be achieved in the restaurant industry through automation?
Yes, with caveats. In TvBet, automation dramatically shortened regression cycles. In HoReCa, external integrations and the B2B layer add complexity. We have already reduced manual cycles. With careful CI/CD optimization and coverage of critical regression scenarios, test cycles can be significantly shortened. It may not reach two hours, but the improvement is tangible.
Your fintech experience (WalletOne/Stoloto) involved handling millions of transactions. How useful was this when load testing restaurant systems?
Extremely useful. Fintech taught me to handle high volumes of parallel operations, ensure transactional reliability, and integrate with regulatory systems. These skills have found direct application in optimizing B2B platforms in our company. Scaling mechanisms, monitoring, and log analysis from fintech adapted well to HoReCa challenges.
You’ve said that one prevented failure during peak sales can save a restaurant a month’s revenue. Can you give an example when load testing avoided such critical losses?
The same B2B support system is a clear example. Iteratively, we identified and fixed bottlenecks in the database, queues, and caching. After improvements, the system handled 2–3,000 requests per hour and survived real peak loads, preventing large-scale complaints and potential revenue losses for clients. This is why I call testing insurance.
Your career began with electronics and Arduino, and now you serve as a judge for the Technology & Design Awards. What early skills still help you think beyond engineering?
Working with Arduino developed systems thinking and attention to detail — understanding how small components combine into a functional system. This helps in testing and in evaluating projects for awards: not just the code, but design, user experience, and practical value.
You actively write about automation and the future of QA. How do you think the role of load testing will change in the era of AI tools?
AI will automate routine tasks such as generating scenarios and preliminary analysis. However, human oversight will remain critical: understanding context, business logic, and strategic validation. Testing will evolve — engineers will orchestrate AI with CI/CD, focusing on interpreting results and assessing architectural risks.
Your expertise spans multiple industries and international projects. What unique value did you bring specifically to the restaurant business?
Cross-industry expertise allowed me to adapt best practices from fintech and gaming to HoReCa: integration reliability, monitoring, CI/CD, and load modeling. Thanks to these approaches, the company was able to provide reliable service to thousands of customers.
QA is often perceived as a “backstage” function invisible to clients. What do you consider your biggest achievement in making your results tangible for the business and end users?
Transparency was key: dashboards, clear reports, and regular review sessions turned QA into a visible risk management tool. Demonstrating fixed bugs before release and measurable metrics reduced complaints and increased customer trust. QA became not just a support function, but a driver of stability.
Looking at the future of HoReCa, where digitalization is just picking up, what trends do you see, and what role will load testing play?
HoReCa is moving into AI and low-code: personalization, predictive analytics, kitchen automation, and rapid local app deployment. The market is growing at 13–15% annually, potentially reaching $6.4 trillion by 2028. As automation grows, load testing will become mandatory “insurance” to scale systems without failures. Tools will evolve with AI, but the human strategist will remain essential.
