What we do · Data and web
Object caching with automatic failover
An object cache is what keeps WordPress, Magento and Laravel from asking the database the same question thousands of times a minute. We run it as a replicated trio with automatic promotion, so a cache node failing never turns into an uncached, overloaded database.
What it is
Valkey (and Redis, its compatible ancestor) holds computed results in memory: options, menus, session data, query results, rendered fragments. That makes the cache part of your availability, not just your performance. A single cache instance is a hidden single point of failure, and we do not build them.
How we build it
- Three nodes, one primary and two replicas, on separate hosts with hard anti-affinity so no two land on the same hardware.
- Three Sentinels with a quorum of two watch the primary. If it fails, they agree, promote a replica and tell clients where the new primary is.
- Applications connect through Sentinel, using the service name rather than a fixed host and port. A promotion is transparent to PHP: no configuration change, no restart.
- Fast detection by design. Sentinel is tuned to detect a dead primary in a few seconds. A brief, unnecessary failover costs far less than a long window with a dead primary.
- Isolation where it matters. Smaller properties can share a cluster through separate logical databases; large or critical sites get their own instance, so one site's cache event can never empty another's.
We integrate the application side as well: the WordPress object cache drop-in configured for Sentinel, Laravel's cache and session drivers, or your framework's equivalent.
What it protects you from
- One cache server failing and every site behind it falling back to the database at once.
- A shared cache filling up and evicting the keys every site depends on.
- One site's flush or bad deploy emptying the cache for its neighbours.
- Manual intervention in the middle of the night to point applications at a new cache host.
- Stale entries surviving a release, because we flush and warm the cache as part of every deployment plan.
In practice
Kill the primary, on purpose. On a multi site publisher's platform we stopped the cache primary during acceptance testing. Sentinel promoted a replica in about six seconds and every site recovered on its own, with no human action. On an analytics platform built later, the same test measured about seven seconds.
Why EuroVPS
- Sentinel based failover as the default, not an upsell.
- Anti-affinity enforced, so replicas never share hardware with their primary.
- We configure the application side too, so failover actually reaches PHP.
- Every build is failover tested before handover, with the measured time written down.
FAQ
Valkey or Redis? Valkey is an open source, Redis compatible fork. Applications and client libraries work unchanged. We run whichever your stack requires.
Will our site go down during a cache failover? Requests in flight during the few seconds of promotion may miss the cache or retry. Then everything continues on the new primary automatically.
Do we need this for a small site? A single instance is fine for a small site whose database can carry the full load. Once losing the cache would overload the database, it should be replicated.
Can sessions live in it? Yes. With replication and Sentinel, sessions survive the loss of a cache node.
Can you look after our WordPress object cache plugin? Yes. We configure and maintain it as part of the stack.
Want a cache that fails over before anyone notices? Talk to an engineer.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.