📄️ Overview
Let's discover what the KanthorQ architecture is and how components communicate with each others.
📄️ Subject
A Subject in the KanthorQ system is a hierarchical entity that categorizes events. Understanding how subjects are structured and used in KanthorQ is essential for leveraging them effectively in your workflows.
📄️ Publisher
The Publisher is responsible for inserting events into the KanthorQ system. Technically, it functions as a simple query that inserts events—nothing particularly special happens at this stage. However, when dealing with the insertion of multiple events in a short time, there are important performance considerations worth discussing.
📄️ Event
An Event in KanthorQ represents a data transfer object (DTO) used to communicate between publishers and streams.
📄️ Stream
A Stream in KanthorQ is a persistent, append-only event group designed to serve specific purposes. For instance, you can create a stream named order_update to store all events related to orders within that stream.
📄️ Task
If an Event is the DTO for client-to-KanthorQ publisher communication, then a Task is the DTO for KanthorQ subscriber-to-client handler communication.
📄️ Consumer
Consumer is a subject-specific filter for events from a stream, storing metadata about how those events should be processed. A single consumer can only subscribe to one subject, but you can have multiple consumers for a single subject.
📄️ Subscriber
The Subscriber is the most complex component in the KanthorQ system, but its purpose is simple: it pulls tasks, processes them, and moves them to their next state. If something goes wrong with a task, the Subscriber allows you to retry it, either manually or automatically.