Skip to content

QTasks Architecture

This section describes the architectural principles of QTasks: how the framework is structured at the level of components, execution threads, and data transfer. It does not cover user capabilities, APIs, or usage examples—the focus is exclusively on internal structure and engineering solutions.

QTasks is designed as a component task framework in which each element performs a strictly limited role and interacts with other elements through formalized contracts.

QTasks is designed as a component-based task framework in which each element performs a strictly limited role and interacts with other elements through formalized data contracts. The architecture is focused on extensibility, predictable behavior, and the ability to replace any component without rewriting the entire system.

Who is this section for?

The "Architecture" section is aimed at developers who:

  • integrate QTasks into complex projects;
  • develop their own components or plugins;
  • analyze performance and execution flows;
  • make architectural decisions at the system level.

Understanding this section is not essential for everyday use of QTasks, but it becomes critical when deeply integrating and extending the framework.

Basic architecture philosophy

QTasks is based on the principle of component minimalism. A component implements only its own responsibility and does not contain logic related to other levels of the system. This achieves:

  • loose coupling between parts of the system;
  • the ability to independently replace the broker, worker, storage, and auxiliary components;
  • predictable task lifecycle;
  • simplified testing and debugging.

The architecture is not built around a specific transport, storage, or execution method. These details are moved outside the core and connected through the implementation of abstract interfaces.

Component Model

QTasks consists of a set of logically independent components that form a task processing pipeline. The components do not call each other directly and do not exchange business objects. All interactions occur through data schemas and clearly defined entry points.

This approach allows the system to be viewed as a set of isolated nodes connected by data flows, rather than as a monolithic process with shared state.

This approach allows the system to be viewed as a set of isolated nodes connected by data flows, rather than as a monolithic process with a shared state.

Control and data flows

The QTasks architecture distinguishes between two types of flows:

  • control flow — determines the order in which task processing stages are executed;
  • data flow — describes what data structures are transferred between components and in what form.

The task at each stage is represented not by a Python function or object, but by a data schema suitable for serialization, logging, storage, and transfer between processes or nodes.

Asynchrony and parallelism are considered properties of specific components and their environment, rather than the global state of the entire system.

Boundaries of responsibility

Each QTasks component has a clearly defined area of responsibility. Components are unaware of each other's internal implementation details and rely only on public contracts.

This rule deliberately limits the "intelligence" of components, but makes the system resilient to increasing complexity and the emergence of new usage scenarios.

Extension without changing contracts

QTasks does not have a "core" as a separate monolith that needs to be extended. The system consists of components linked by contracts — abstract classes and data schemas.

Extension is achieved in two basic ways:

  • replacing the implementation of a component while preserving its contract (e.g., different transport, different storage model, different executor);
  • adding new components or extension mechanisms that connect to existing flows without breaking existing contracts.

The key principle here is system evolution through contracts: as long as the contract is stable, the internals of the component can be changed freely, and the ecosystem around it remains compatible.