External in-memory cache option

An option to use an external in-memory data store like Redis or Aerospike by using an adapter. This would help in allowing users to scale ghost horizontally behind load balancers.

This is definitely something we have on our radar for the future as Ghost gets more complex features & use cases.

The current expectation is that Ghost would be run on a single instance, with a cache or multiple load balanced caches in front of it to handle scaling.

The reasoning is that for most cases, it’s the content that needs to be highly available, not Ghost or the Admin panel. Even serving slightly stale content or API responses is usually acceptable.

We 100% realise that over time, as more people depend on the API and so on, this will change and so it’s something we’re thinking about now, with a view to slowly refactoring behind the scenes as opposed to it becoming a project all on its own.

2 Likes

Using caches is fine for HA but what about resiliency and in particular failover? This architecture has a single point of failure, if the ghost node goes down the caches have nothing to hit.

Is there a way that Ghost suggests to implement failover?

1 Like

A related discussion: https://github.com/cobyism/ghost-on-heroku/issues/167

1 Like

We use Ghost with a lot of our customers, and being able to provide geographically-replicated instances for low latency and failover is something we get a lot of demand for.

Seeing how needed this is for us, we wouldn’t mind implementing this ourselves.
@Hannah If we were to start a pull request for this feature, are there chances of this being accepted?
I’d like to know if this is something the Ghost core team would welcome, or whether it’s something that’s explicitly “not on the roadmap”

This is something we’re looking into prioritising. Will DM to talk about collaboration.