Bulletproofing your Symfony application for Black Friday

This blog is based on Thomás Di Luccio's talk "Bulletproofing for Black Friday" from the Symfony 2024 conference. Thomás is a Developer Relations Engineer at Upsun. We utilized AI tools for transcription and to enhance the structure and clarity of the content.

Picture this: You're a small ticketing startup that just landed a major deal with a large venue. After months of building features and preparing for launch, the big day arrives—season ticket sales go live. This venue could generate up to half of its yearly revenue in a single day. The stakes couldn't be higher.

At 10 AM, ticket sales begin. Online customers, on-site visitors, and mobile app users all access the same API simultaneously. For 45 minutes, everything seems fine. Then, gradually, the application starts slowing down. An hour in, everything crashes completely.

This was precisely what happened to Thomás and his team years ago. It was a crushing failure that affected not only that major client but also all their customers. The mood in the office was devastating, and nobody knew what had gone wrong or how to rectify the situation.

However, this failure marked the beginning of a journey into application performance and scaling, one that you won't have to repeat.

The core problem: building features vs. building for scale

The fundamental issue wasn't with Symfony or any particular technology. The problem was simple: the team was so focused on shipping features that they completely overlooked preparing for high-traffic scenarios.

"We were so focused on building the product, shipping features, assembling features, that we were missing something essential, getting ready for the big day," Thomás explains.

This is a common trap in e-commerce and any business with peak traffic periods. Teams build excellent functionality, but often overlook the fact that success means more users, and more users can overwhelm unprepared systems.

Four essential strategies for bulletproof applications

1. Stress test your application relentlessly

The first lesson is obvious but often overlooked: stress-test your applications before the critical day arrives. But this isn't just about running a few load tests; it's about systematically breaking your application.

Break your application intentionally.

Don't just test your application, break it. Be creative. Find new ways to push it to failure. As Thomás puts it, "Don't let this be in the hands of your users because they are mad people and they will break it in ways you won't be in control of."

Invest in load testing tools.

Choose tools that work for your team and stick with them. Popular options include:

• Locust (Python-based, highly flexible)
• Gatling (Java-based, enterprise-focused)
• Various SaaS solutions for those preferring managed services

The key is finding the right balance between time investment and money spent to create a setup that anyone on your team can use reliably.

Create real user journeys.

Generic load testing isn't enough. You need to simulate actual user behavior:

• Study your analytics to understand real user patterns.
• Map out complete user journeys from homepage to checkout.
• Use your APIs to fetch real data (product IDs, categories, search keywords).
• Create modular test functions that can be combined like Lego blocks.

Don't forget edge cases.

In the ticketing company's case, their nemesis was groups of elderly theater enthusiasts who would send one person to buy dozens of tickets for the entire group. These large cart scenarios created massive computational loads that weren't accounted for in normal testing.

Always test extreme scenarios:

• Large shopping carts with 50+ items.
• Complex user configurations.
• Heavy computational processes.

Make it one-click simple.

Anyone on your team should be able to run comprehensive load tests with a single command or button click. This removes barriers to regular testing and ensures that tests are actually run.

Find your breaking points.

Load testing reveals two critical numbers:

• The point where your application starts slowing down
• The point where it crashes completely

Understanding these thresholds is crucial because there's often a direct correlation between concurrent users and revenue. Knowing your breaking point means knowing the maximum revenue your current infrastructure can generate.

2. Always work on production copies

Never stress test in production. This seems obvious, but the challenge is creating truly accurate copies of your production environment.

The Upsun approach

Upsun, where Thomás works, provides Git-based Platform-as-a-Service that makes this seamless. You describe your infrastructure needs in YAML files committed to your repository:

• Symfony applications with PHP 8.3 or 8.4
• Frontend applications in Node.js
• Data science pipelines
• Go workers
• Any combination of services your application needs

Every commit creates a new version, and every branch creates a complete copy of the parent environment, regardless of its complexity.

DIY Solutions

If Upsun isn't an option, invest in creating similar capabilities:

• One-command environment cloning.
• Automated infrastructure provisioning.
• Identical configurations across environments.

For e-commerce applications, this capability is essential.

3. Integrate observability into everything

Having load testing and staging environments isn't enough if you can't understand what's happening inside your application during stress tests.

What is observability?

Observability is "the ability to witness the behavior of an application, detect bottlenecks, and improve performance." Think of it as bionic glasses for your application—a way to see through the black boxes and make educated decisions.

Key observability features

Modern observability tools like Blackfire provide several essential capabilities:

• Monitoring: Track both CLI and HTTP traffic across your entire application stack.
• Continuous profiling: Lightweight data collection with minimal overhead (0.05-0.1% performance impact) that works across multiple languages: PHP, Python, Node.js, Go, Ruby, Rust, and Java.
• Time frame comparison: Compare quiet periods with load testing or actual Black Friday traffic to assess performance. This visual comparison shows which parts of your application consume proportionally more resources under load, helping identify bottlenecks.
• Deterministic profiling: Deep, precise profiling for specific requests that shows exactly how your code executes, including loops, function calls, and resource consumption across all dimensions.
• Performance testing: Automated performance tests that can prevent performance regressions from being merged into production.
• Infrastructure monitoring: Track HTTP traffic and resource consumption for all services and containers to ensure proper scaling.
• Making educated decisions
• The goal is to enhance user experience, quickly identify areas for improvement, and ensure your application scales effectively. Whether you use Blackfire or alternatives, invest in tools that provide similar insights.

4. Scale intelligently and granularly

The final piece is understanding how to scale effectively. This means answering a complex question: "What part of your application needs what resources to achieve what results?"

Start with your objectives

Define your scaling scenarios:

• Quiet periods (baseline traffic).
• Peak periods (Black Friday, product launches).
• Intermediate scenarios.

Run tests for each scenario until you understand the exact requirements.

Identify precise requirements

Use your testing and observability tools to determine:

• Resource requirements per container
• Whether you need load balancing (the answer isn't always yes)
• Optimal instance counts for different traffic levels

Make cost-based and performance-based decisions using real data, not assumptions.

Don't forget workers

Scale your background workers alongside your web applications. Ensure they have sufficient resources in properly configured containers.

Fine-grained resource allocation

Upsun allows granular resource allocation; you can add more memory to one container while reducing CPU in another where it's wasted. You can also scale the number of instances with automatic load balancing.

Avoid always-scaled solutions

Many applications run at maximum scale year-round because their hosting providers make it difficult to scale up and down. This wastes money and has an unnecessary carbon footprint. Find solutions that allow dynamic scaling based on actual demand.

The bulletproof application framework

When you combine these four strategies, you create a bulletproof framework:

1. Stress Testing: Break your application systematically in controlled environments
2. Production Cloning: Test on perfect copies of your production setup
3. 360° Observability: Understand what's happening inside your application during stress
4. Fine-Grained Scaling: Scale precisely based on real data and requirements

The real-world impact

Remember the original failure? The bottleneck turned out to be large shopping carts that the team hadn't anticipated. Groups of theater enthusiasts were purchasing 50-100 tickets in a single order, creating massive computational loads for seat allocation, pricing calculations, and ticket generation.

But the technical issue was just a symptom. The real problem was the team's isolation from actual users. They were building features based on assumptions rather than understanding how venues actually sell tickets.

"We were totally isolated in the engineering department, just shipping features from a backlog. We weren't with the people in the venue seeing how they actually work, how they actually sell things," Thomás reflects.

The goal is transformation: moving from a state of panic during high-traffic events to one of confident relaxation. When you have proper stress testing, production cloning, observability, and scaling in place, you can approach Black Friday knowing you're entirely in control.

Instead of rushing around trying to fix things, you can actually enjoy a drink while monitoring systems that you know will handle whatever traffic comes their way.

A short Q&A from the room

Q: How much monitoring is enough?
A: Keep continuous profiling on. For request monitoring, a 10% sampling rate is a good starting point for many applications. Extremely high-traffic apps can achieve lower traffic while maintaining statistical soundness. Early wins from using these tools often offset their overhead.

Q: What caused that original outage?
A: Huge carts plus heavy seat allocation and ticketing logic, combined with choices made while focusing on shipping features, not on how real users would act on launch day. Even printers were fed oversized images. Tests were missing. The fix began with observing real workflows and tightening the system.

Q: How do I avoid false confidence in perf tests?
A: Write performance tests alongside unit and integration tests. Start with the most critical user journeys—test causes, not just outcomes. For example, assert “fewer than N SQL queries” instead of only “under 10 ms,” so you do not pass due to warm caches while hiding actual costs.

Q: What about third-party services during stress tests?
A: Point preview environments at sandbox accounts via environment variables. Use production credentials only in production. That way, you can test safely without burning through real quotas.

The bottom line

Don't wait for your own disaster story. Start stress testing now, invest in proper tooling, and build systems that can handle success. Your future self and your users will thank you when the next Black Friday arrives and everything just works.

The difference between a successful high-traffic event and a catastrophic failure often comes down to preparation. Make that preparation a priority, not an afterthought.