> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dittofeed.com/llms.txt
> Use this file to discover all available pages before exploring further.

# System Architecture

This page describes Dittofeed's system architecture. This is great for understanding how Dittofeed works, especially if you intend to [self-host](/deployment/self-hosted), or contribute to Dittofeed.

## Summary

Dittofeed encompasses a collection of components that work together to scalably ingest user events, and send those users personalized messages. This is accomplished through a series of steps.

### Steps

1. Clients send User Events to the API from their applications.

2. These events are then written to ClickHouse. Optionally, they're buffered in Kafka first.

3. Dittofeed's worker issues queries to ClickHouse on a short polling period for the following purposes:

   a. Process new events to update [Segments](/resources/segments) and [User Properties](/resources/user-properties) assignments within Clickhouse.

   b. Retrieve [Segment](/resources/segments) updates, and signal subscribed [Journeys](/resources/journeys).

   c. Retrieve [Segments](/resources/segments) and [User Properties](/resources/user-properties) assignments from Clickhouse to persist back into Postgres for rapid, row-wise lookups.

4. User [Journeys](/resources/journeys) are processed by the worker, and progress in response to signals, and the passage of time.

5. Journeys issue requests to Messaging Services, to send messages to end users on one or more [Channels](/integrations/channels).

### Diagram

<Frame>
  <img src="https://mintcdn.com/dittofeed/MR-erTsdiKcJhyyj/images/architecture-solid.png?fit=max&auto=format&n=MR-erTsdiKcJhyyj&q=85&s=d32f1b457589a85a22f63ab981586295" alt="Architecture Diagram" width="4346" height="5216" data-path="images/architecture-solid.png" />
</Frame>