Shopware High Availability: Strategies for 99.9% Uptime

For an online shop in the mid-sized business or D2C sector, downtime is much more than a technical nuisance. Every minute of unavailability means direct revenue loss, decreased customer trust, and wasted budget on ongoing marketing campaigns.

Agencies aiming to grow and manage larger brands cannot avoid the demand for Service Level Agreements (SLAs) of 99.9%. However, this level of availability cannot be physically guaranteed with a classic single-server setup. A hardware defect, a stalled database process, or a simple kernel panic on the host system immediately leads to a standstill. High availability requires a rethinking of architecture: moving away from single servers to distributed systems.

1. The Application Layer: Redundancy through Pod Orchestration

The first step towards high availability in a Kubernetes environment is the horizontal distribution of the Shopware instance. Instead of running the shop as one large process, it is divided into several small, identical units (Pods).

• Multi-Node Operation: The Pods are automatically distributed by the scheduler across different physical servers (Nodes) in the cluster. If a server completely fails, Kubernetes immediately notices this and restarts the missing Pods on the remaining healthy servers.
• Health Checks: Kubernetes continuously checks the status of each Pod (Liveness and Readiness Probes). If a Shopware process no longer responds correctly—perhaps due to a PHP memory error—that specific Pod is isolated and restarted, while the other Pods continue to process traffic without interruption.

2. The Database Layer: No Compromises on State

The database is often the bottleneck and the most critical “Single Point of Failure.” For 99.9% availability, we rely on highly available database clusters (e.g., MariaDB or MySQL with Galera or Group Replication):

• Automatic Failover: A cluster consists of at least three nodes. If the primary write node fails, the remaining nodes elect a new “leader” in a fraction of a second. The application continues to write without manual intervention.
• Point-in-Time Recovery (PITR): In addition to daily backups, transaction logs (Binary Logs) are continuously secured. This allows the shop to be restored to any second in the past in case of an emergency—a crucial protection against human errors or corrupted data imports.

3. Shared Resources: Redis and File System

To allow multiple shop Pods to work simultaneously, they must share information without blocking each other:

• Centralized Session Management: Sessions are not stored locally in the server’s file system but in a highly available Redis cluster. This way, a user can seamlessly move from one Pod to another during their shopping (e.g., during an update or scaling operation) without losing their shopping cart.
• Replicated File System: Product images and documents are stored on a distributed storage system, which all Pods can read and write to simultaneously. This prevents inconsistencies between instances.

Conclusion: Stability as Standard

True high availability for Shopware is not a “feature” that can simply be switched on but is the result of a consistently well-thought-out infrastructure. By combining orchestral distribution, database clustering, and centralized session management, we eliminate the Single Point of Failure.

For the agency, this means no longer fearing hardware failures at the host. For the shop operator, it means absolute reliability, even when traffic massively increases or maintenance work is being carried out in the background.

FAQ

Why isn’t a backup enough for high availability? A backup secures the data but not the operation. A restore after a server failure often takes hours. High availability aims to make the failure imperceptible through redundancy.

What is the difference between vertical and horizontal scaling? Vertical (Scale-up) means giving an existing server more CPU or RAM—this has physical limits and often requires a restart. Horizontal (Scale-out) means adding more instances (Pods). This happens during operation and provides true redundancy.

Does a high-availability architecture make the shop slower? On the contrary. By distributing the load across multiple instances and using fast in-memory databases for caching (Redis), response times usually improve noticeably, especially under load.

How is traffic distributed across the different Pods? A Load Balancer (Ingress Controller) in the Kubernetes cluster receives all requests and intelligently distributes them to the healthy Pods. It automatically detects when a Pod is not ready and removes it from the distribution.

Do high-availability setups cost significantly more? Infrastructure costs increase slightly because more instances are running. However, this effort is negligible compared to the costs of a multi-hour total failure during a high-revenue phase like Black Friday. Additionally, Kubernetes optimizes resource utilization more efficiently than traditional VMs.