Customer Stories

Customer stories

Scenarios showing how the same infrastructure components are assembled for different needs. Each story starts with a problem and ends with the decision made.

Request a quote All solutions

Why we publish these

Infrastructure decisions often stay abstract: what "high availability", "scalability" or "redundancy" mean in practice only becomes visible in a concrete scenario.

The stories below describe real requirement patterns we've encountered. Customer names and commercial details are not shared; what is described is the shape of the problem and the reasoning behind the decision. If one resembles your situation, we can discuss whether the same approach would work for you.

Scenarios

Four different needs, four different decisions

E-commerce

From a site that crashed on campaign day to planned scaling

Situation: During the two big campaign periods of the year, the site stopped responding in the first hour of peak traffic. Server capacity had already been increased, yet the problem kept recurring.
Approach: Zabbix metrics showed the bottleneck was not CPU but the database connection pool. Web, cache and database tiers were moved onto separate servers and Redis was deployed with replication. Capacity increases were scheduled to apply three days before each campaign.
Outcome: The site ran without interruption in the following campaign period, and because resources were scaled back afterwards the extra capacity never became a permanent cost.

Manufacturing

An ERP moved from the server room to the cloud

Situation: The ERP server ran in an in-house room. Two cooling failures had halted production planning, and sourcing spare parts took days. Branch access was provided over a public IP with open ports.
Approach: The ERP and its database were split onto separate servers and moved to the Istanbul location. Branch access was moved to a VPN tunnel terminated on pfSense and the open ports were closed. A rehearsal measured the cutover duration, and the real migration was scheduled for a weekend.
Outcome: Responsibility for hardware, power and cooling left the operation. Data stayed in-country, and branch access no longer requires any internet-facing ports.

Services

From backups assumed to work to backups that actually restore

Situation: The organisation had a backup plan but had never run a restore test. On review, the backup job had been silently failing for months and nobody had noticed.
Approach: Backups were moved onto Veeam and onto storage separate from production. Job results were wired into monitoring, so a failed job now raises an alert. The restore scenario was executed into a separate environment, its duration measured, and put on a schedule.
Outcome: That the backups work is no longer an assumption but something verified on a schedule. The possibility of silent failure was closed off by the monitoring layer.

Software

Separating an application that slowed whenever reports ran

Situation: While end-of-day reports ran, users found the application unusably slow. The first suggestion was a bigger server, but the problem came from contention rather than capacity.
Approach: A read replica was added via streaming replication and reporting queries were directed to it. Heavy jobs were moved into a low-traffic window, and enabling the slow query log surfaced several missing indexes.
Outcome: Report runtimes shortened and the slowdown on the transactional side disappeared — with no need to grow the server.

Let's plan your infrastructure together

Tell us what you need and we prepare a configuration and pricing specific to you. We don't sell fixed packages; we build the deployment, licensing and backup plan with you.

Request a quote Technical support

or reach us directlyinfo@eg678.com +90 (552) 890 8567