Tiered storage cookbook

Introduction

In event-driven systems, it's important that your event store can store events quickly and indefinitely. But fast disks can be expensive and have limited storage space. Larger storage options, on the other hand, are less expensive but slower. In this blog post, we'll look at how to use Axon Server's tiered storage to find a good balance between speed and cost using real-world examples.

Use Case: Creating hybrid storage

A common way to set up tiered storage is to use SSDs for the first level, which makes it easy to read and write data quickly. HDDs, which are slower but cheaper and have more space, make up the second level. For example, in Google Cloud, you can use Local SSDs for the first tier and Persistent Disks for the second. This hybrid storage method is good for applications like e-commerce platforms and real-time analytics that need quick response times and deal with a lot of data.

Use Case: Reducing the number of long-term replicas

The secondary nodes of the Axon Server can be used to cut down on the number of copies and move old data to a different node with cheaper storage. This method saves money on storage costs while keeping the required level of performance. For example, if a bank needs to store transaction data from the past, it can use secondary nodes to move older transactions to cheaper, slower storage while keeping the most recent transactions on primary nodes with fast storage so they can be accessed quickly.

Use Case: Removing old snapshots

In Axon Server, snapshots are one of the way to speed up the time it takes to load the state of an aggregate. We only need the most recent snapshot for an aggregate, so in most cases, you can safely delete older snapshots. To do this, set up a black hole storage tier for snapshots and switch to a strategy for creating snapshots based on time. You can use the "conditional-remove" feature if you don't want to delete an aggregate snapshot that doesn't have a newer snapshot. This is helpful for applications that frequently need to create snapshots and want to find a balance between the cost of storage and how quickly they can load the state of an aggregate.

Use Case: Integration context

Some applications may require integration context to communicate with external systems. For example, in supply chain management integration systems that need to interact with various external systems, events may become obsolete very quickly. Once these events have been sent to subscribers, they can be safely removed. By choosing an ephemeral context for integration purposes, you can effectively reduce storage costs once your events are no longer needed.

Use Case: Archiving and cold storage

Lazy-initialized tier types for archiving or cold storage, like Amazon S3 or Google Cloud Storage, are not yet supported, but Axon Server may add support for them in the future. Cold storage and archive tiers are good for applications like medical record systems and legal document management that need to keep data for a long time for compliance reasons.

Use Case: Safely removing old Events

In some applications, it may be necessary to safely delete older domain events, especially when snapshots are already in place for the associated aggregates. Utilizing the black hole tier with conditional removal can help achieve this.

For example, in a customer rewards program where points earned through purchases expire after a specific time, older event data related to expired points may no longer be relevant. In these situations, you can use the experimental conditional removal feature that Axon Server gives you. With conditional removal, you can only remove an event segment if every event in it has been included in a snapshot before. This makes sure that the aggregate state is always valid, even when events are removed.

Conclusion

By understanding and using these strategies, you can improve the speed and cost-effectiveness of your event store, making sure that your Axon Server setup meets the needs of your specific applications.

Stefan Dragisic
Senior Software Engineer Stefan has years of experience and passion to software architecture, reactive programming and JVM technologies.
Stefan Dragisic

Share: