Case Study

Microservices with Hazelcast at a Global Pizza Delivery Chain


This global pizza delivery chain operates in 82 countries, making it the second-largest franchised pizza chain in the world. Today, it operates more than 12,600 pizza restaurants around the world and delivers more than 1 million pizzas each day.

This global chain is all about harnessing the power of technology to make the pizza ordering experience better to differentiate themselves from the competition. They’ve identified key ways customers would benefit from online tools. A custom pizza creator represents an innovation in online food ordering, enabling customers to make their favorite selections and see their pizza come to life on a computer screen. Their tracking service is another innovation in food delivery that enables customers to follow the progress of their order from the time it’s placed until it arrives at the door. They’ve also added member profiles to their website, as well as various ordering channels, which enable customers to leverage technology to place their order via text, smartphone, tweet, and more.

Their innovations help them better deliver on their promise to bring customers great pizzas, pasta, sandwiches, desserts, and drinks as efficiently as possible.

The Customer’s Requirements

The decision to use Voldemort was made early on during the emergence of Hadoop, Cassandra and other distributed KV stores.

The global pizza delivery chain utilized Voldemort containers for custom replication between data centers. Although it found the performance to be acceptable, replication was unreliable which ultimately affected customer order history and profile data. Frustratingly, their early adoption of Voldemort meant that the upgrade path was difficult and there was also the quandary that there was no tangible support available. This led the development team to examine more modern storage architecture, with one experiment involving the swapping of Voldemort for SQL Server – a sound concept, but an idea that did not achieve the required performance results. The global chain also looked at Memcached, but again the results weren’t compelling enough.

At the same time that this re-evaluation was occurring, a social media project was running which required de-duplication of data coming in from multiple copies of the Twitter feed. It was this project which led them to Hazelcast as a microservices alternative to Voldemort. When the Twitter project team realized it was sending out duplicate messages because it had multiple nodes consuming the same feed, it accepted that it needed a solution to coordinate data between multiple nodes.

The potential for Hazelcast as a replacement became a reality when the global pizza delivery chain combined SQL Server with Hazelcast – the results providing ample flexibility and tooling to allow the company to meet its performance goals. It was then, that they began to appreciate that Hazelcast could serve as the backbone of its microservices architecture – a lightweight, easy to use, simple to deploy alternative

Hazelcast for Microservices

The initial plan was to have a single large cluster that would hold all of its “hot” data, with individual microservices using this shared resource. This was driven by the initial belief that Hazelcast could only be used as a caching layer. Internally this quickly caused frustration as load could not be isolated and change control became problematic. However, following consultation with Hazelcast solution architects, it was mutually agreed that Hazelcast should be embedded within their microservices – enabling individual services to be free to configure their instances as needed to meet the individual requirements of each service.

Within their microservices architecture, Hazelcast is now embedded in a plethora of services for distributed data. Developers use IMaps as they would Maps to develop services and evaluate capacity, distribution and replication configurations prior to deployment. An interesting use case is the system for tracking drivers. Driver tracking receives real-time feeds from delivery vehicles as well as events from the stores and makes this data available to front end services for real-time map display.

Today, Hazelcast is embedded in 15 of the pizza chain’s production microservices with dozens of data structures and millions of in-memory objects. It is being used for a number of different purposes including:

  • In-memory cache with and without SQL database support
  • Deduplication of event data
  • Non-durable queuing

Hazelcast has enabled the global pizza delivery chain to make optimal usage of its resources and has allowed developers to think in terms of well-known data structures such as Maps, Queues, etc.

Customer Success

Previously, they treated data as unstructured JSON, for both storage and compute models. Using Hazelcast enables them to use Java objects and decide on the storage architecture on a case-by-case basis. For example, in some cases it stores the payload as binary data in a SQL database, in others it breaks the objects down into their individual fields, and sometimes it just doesn’t bother to store them in persistence at all or load them at boot time from files.

Through the use of Hazelcast Management Center, they are able to monitor and manage their nodes that are running Hazelcast. In addition to monitoring the overall state of its clusters, they can analyze and browse their data structures in detail, update map configurations, and take thread dump from nodes. Using the management console, the development team is getting a much better insight into what the system is doing. By leveraging Hazelcast for its microservices platform, the global pizza delivery chain is able to focus on solving business problems rather than reinventing the infrastructure wheel. Once Hazelcast was in place, they were able to rely on it and build additional services and functionality on top. With Hazelcast, ongoing development, performance improvements, and active user support make it the pizza chain’s continued go-to platform for network distribution and in-memory data storage.

Recently, they introduced a new service that became deadlocked when a corrupt member joined a cluster. Within 24 hours Hazelcast’s Technical Support had replicated and resolved the issue, even though the service was not yet in production. The root cause was due to the ordering of startup operations in the Spring Boot and Hazelcast contexts, which would not have existed if the data grid was external to the application. Hazelcast provided a workable solution almost immediately and a patch was scheduled for review and inclusion into Hazelcast within 48 hours.

In the future, global pizza delivery chain intends to deploy Hazelcast within its next generation of order and customer storage systems, allowing it to decouple the performance of its system from the SQL database which is providing long-term storage.