Work Agenda
Team
- 2 DevOps engineers
- Project manager
Project timeframe
July 2025 – ongoing
The Main Project Challenge
The key obstacle we had to address was repeated DDoS attacks on the platform, as they were regular and disruptive.
Each serious attack meant the website going down. On top of that, our client’s website visibility in search engine results was affected negatively, which only made the situation worse.
At the same time, another problem was affecting day-to-day operations. The deployments didn’t happen automatically, monitoring was limited, and responding to issues consumed more time and manual work than necessary.
Our Solutions
Server optimization
We began by strengthening the overall system to better handle heavy loads. Initially, all applications were running on a single Hetzner bare-metal server, with the database hosted on a separate server. Later, we distributed applications handling different types of traffic across three servers.
When all applications were running on a single server, there was only one Redis instance. It’s used for caching and session storage, acting as an intermediary between the application and the database.
After distributing applications across three servers, we placed Redis next to each application. However, it was important to consider that traffic between Hetzner bare-metal servers passes through network channels. These servers were connected via one-gigabit channels, and when Redis attempted to communicate with the database, it overloaded these channels. As a result, there was insufficient bandwidth left for organic traffic.
To address this, we upgraded the network channels from one gigabit to ten gigabits, which significantly improved the situation. However, because Redis instances were running independently on each application server, desynchronization issues began to occur, and clients’ customers started receiving outdated or inconsistent data.
We then decided to move Redis to a single, dedicated server. This centralized Redis instance became the primary one.
Yet, we still had to implement a backup Redis strategy, since during a DDoS attack, traffic volumes can become so large that even a ten-gigabit channel—the maximum available from the provider—can become overloaded.
To mitigate this risk, we reintroduced Redis instances on each application server but kept them disabled by default. We created a script that detects the start of a DDoS attack: when triggered, the centralized Redis instance gets disabled and the local Redis instances on each application server are enabled. This approach prevents Redis traffic from clogging inter-server communication channels and helps preserve bandwidth.
Below, you can see our server optimization solutions in greater detail: