SlicingDice Documentation

SlicingDice API Docs

Welcome to the SlicingDice API documentation. You'll find comprehensive guides and documentation to help you start working with SlicingDice as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Guides

High Availability & Replication

First time checking our docs? You might want to start with the right foot by reading our Documentation Guide first.

We all know that technology is not perfect and, at some point, can fail. However, there are two things that are totally unacceptable for us: losing your data or having an unauthorized access to it.

Because of that, since the beginning of SlicingDice's inception, we worked hard to have no single point of failure that could affect our ability to store and protect your data.

We currently have three completely independent datacenters from different providers in different countries that operate simultaneously in high-availability configuration.

That means up to two datacenters can fail and our service will continue to support data insertion and querying.

Data redundancy and availability

As we use bare metal dedicated servers for cost and performance reasons, server nodes can fail at any time, so it’s absolutely necessary for us to have data redundancy and availability.

We currently achieve a high level of redundancy and availability by:

  • Replicating our customer’s data across datacenters at least 3 times;
  • Making hourly backups and storing it on our local backup servers;
  • Storing a full daily copy of our backed up data on a remote backup service;

Besides having all these redundancy measures, we also constantly perform unexpected actions and shutdowns on our production environment, similar to the Netflix Chaos Monkey approach, in order to test the resiliency of our services.

Services redundancy and availability

All the services and technologies we use run with redundancy in our three datacenters and some of them are in sync all the time (like MySQL and Aerospike, for example).

This means, for example, that we have three independent Kafka clusters supporting requests from API servers within the same datacenter, but also from remote datacenters in the event of service failure of that datacenter.