Features of EventStoreDB

Table of contents

Reading Time: 4 minutes

Introduction

EventStoreDB is an Event-Specific Database. You may save each state change as a distinct event, in a contrast to state-oriented databases that simply keep the most recent version of the entity state.

List of Features of EventStoreDB

EventStreams
Indexes
Projections
Persistent Subscriptions

EventStreams

Stream MetaData, Reserved Names and Event MetaData

Stream MetaData

In EventStoreDB, every stream has a corresponding metadata stream that contains a prefix of “$$”, for example, the metadata stream for root is $$root. You can edit various metadata values in EventStoreDB, and you can add your own information to stream metadata that you may use in the code.

Reserved Names

EventStoreDB prefixes every internal data with a $ character. As a result, unless otherwise specified below are some reserved names, we shouldn’t use with a $ prefix as event names, metadata keys, or stream names.

Internal reserved names

$maxAge : depending on dates, generates a sliding window When data reaches a certain age, it is automatically withdrawn from the stream and deemed scavengeable. This value is represented by the number of seconds, which is expressed as an integer. This number must be greater than one.

$maxCount : The size of the sliding window is determined by the number of items in the stream. When data reaches a certain length, it becomes scavengeable and automatically disappears from the stream. In this value, the number of objects is specified as an integer. This number must be greater than one.

$cacheControl : This regulates the stream’s head’s cache. The majority of URIs in a stream are indefinitely cacheable, however by default, the head won’t be cached. In some circumstances, setting a tiny amount of caching on the head to let intermediates handle polling may be better (say 10 seconds). An integer that represents the number of seconds to cache is the parameter. This quantity must exceed 1.

Event MetaData

The EventStoreDB contains metadata for each event. You can edit various metadata values in EventStoreDB, and you can add your own information to event metadata that you may use in the code.

Property Names reserved for internal use are “$correlationId and $causationId“.

Indexes

EventStoreDB stores Indexes independently from the primary data files and accesses records by using their stream name. The index map file is known as indexmap, and the index files all have distinctive names. The index map file contains the data checkpoint for the most recent written file. It also indicates the order and level of the index file. The hashes of stream names are used to sort lists called Indexes. EventStoreDB maintains midpoints to connect the stream hash to the actual offset in the file, accelerating the process of finding the right location in the file of an entry for a stream.

As EventStoreDB saves more files, it merges together whenever there are more than 2 files at the same level into a single file at the next level.

Projections

An EventStoreDB component called Projections enables you to reactively attach new events or connect current events to streams.

Projections excel at answering one particular group of queries, called “temporal correlation queries.” There are few people who can effectively run this type of query, which is frequent in corporate systems.

Projections help to make continuous queries a reality. When executing a projection, you can decide whether the query should execute and provide all results at once, or if it should keep running into the future, updating its result set as new results emerge.

Types of Projections

EventStoreDB has 2 types of projections :

Built-in projections
User Defined Javascript projections

Persistent subscription

A typical action is to subscribe to a stream and get updates when something changes. You continue to track the unfolding events as they come.

On the Leader node, persistent subscriptions are active and are not lost when the connection gets cut off. Additionally, this subscription type helps you send messages to lots of employees because it supports the “competing consumers” messaging pattern. EventStoreDB enables at least-once delivery assurances across numerous customers on the same stream by saving the subscription status server-side. It is feasible to have various customer competitions on the same stream, with a guarantee that each group would participate at least once.

Catch-up or volatile subscriptions have a function, and persistent subscriptions do too, but in a different way. Real-time event delivery is the goal of every subscription for connected customers. The server takes care of Persistent subscriptions, but, not like other subscription kinds. Persistent subscriptions are somewhat comparable to catch-up subscriptions. Each has a most recent position from which the subscription begins receiving events. Catch-up subscriptions, on the other hand, must be careful to maintain the last known position on the subscriber side, whereas persistent subscriptions maintain the position on the server.

Because the server determines where events come from and where the subscription should begin receiving them, subscribers that use permanent subscriptions can be load-balanced and process events concurrently. Catch-up subscriptions, which are client-driven and only capable of client-side load balancing, always receive and process events sequentially. Therefore, adopting the competing consumer pattern, which is ubiquitous in the field of message brokers, is possible with persistent subscriptions.