Jitsu Server Architecture
Jitsu Server is a standalone application that doesn't have any requirements such as an inner database or others. Simultaneously some features (e.g. event caching) need Redis, but these features are optional.
Destination — usually a database, but can be a different type of service as well. The destination is a service that contains structured records and supports an INSERT-like statement. Google analytics measurment protocol is an example of a non-DB destination. It has structured records (events) and an INSERT-like interface.
Table — a table in DB or any other structure within the destination.
BatchHeader — describes a structure of batch: fields and types along with table name.
Jitsu's destination can operate in two modes:
Stream — data (events) is being sent to a destination as soon as possible.
Batch — data is being written to local disk and sent to a destination in batches, once in N (configurable) minutes.
Once an event is accepted by the HTTP end-point it undergoes the Context Enrichment step. The logic is different for different sources of events. The purpose of this event is to add additional information to the event which can be useful for further processing. After JSON is enriched it goes to Batch or/and Stream pipeline depending on destination type. Partially multiplexing happens here. If destinations config contains destinations of both types, the event will be sent to both routes.
only_keys filtering is applied.
Batch and Stream pipelines are different, however, they have the same logical steps.
Context Enrichment Step#
In this step, events are enriched with context data:
- Add IP from where the request came from (
- Add UTC timestamp (
- Add generated UUID (
- If request is processed by Server API - add
Lookup Enrichment Step#
Transformation and Mapping Step#