> ## Documentation Index > Fetch the complete documentation index at: https://platform.docs.zenoo.com/llms.txt > Use this file to discover all available pages before exploring further. # Architectural Overview > At the core of the Zenoo Hub is a workflow engine that executes Hub DSL scripts. # Architectural overview At the core of the Zenoo Hub is a workflow engine that executes [Hub DSL](/technical-specification/hub-backend/engine/dsl) scripts. The DSL scripts are used for orchestrating digital-onboarding processes as a series of pages, data transformations and external calls. The DSL-based approach makes it possible to specify digital-onboarding processes in a concise manner. It enables developers to focus on the business logic rather than the complexities of distributed systems. The Zenoo Hub is built on top of [Apache Kafka](https://kafka.apache.org/) using **event-streaming** and **micro-service** architecture. It makes the Hub highly scalable and fault-tolerant. Each workflow execution produces a detailed log of [Execution events](/technical-specification/hub-backend/engine/events) that can be used for troubleshooting, as well as, analytic purposes. alt text ## DSL execution engine At the core of the Zenoo Hub is the DSL execution engine. It executes the [Hub DSL](/technical-specification/hub-backend/engine/dsl) scripts that are used for orchestrating digital-onboarding processes. The host language for DSL is **Groovy**. The DSL scripts are versioned and stored in a **Component repository** as [Hub Components](/technical-specification/hub-backend/components). The Hub employs a component model to facilitate reusability, testability and configurability. Making it possible to build new components from existing ones. Each workflow execution is assigned an **Execution Context** that stores the current state of the execution. The execution contexts are persisted and retrieved using a Kafka Streams **state store**. Leveraging Kafka fault-tolerance capabilities, a replicated changelog topic is maintained to track any state updates. Each workflow execution produces a detailed log of [Execution events](/technical-specification/hub-backend/engine/events). These include life-cycle events, execution requests, responses, errors, executed commands, results etc. The execution events can be very useful for troubleshooting, as well as, analytics purposes. More details can be found [here](/technical-specification/hub-backend/engine/attributes). ## Hub Client A **Hub Client** facilitates an interaction between the Hub and an end user. From a Hub Client perspective, a customer journey is a series of pages. It relies on the Hub to determine what page to display next. Apart from that, it gathers user input and submits data back to the Hub via [Hub Client API](/technical-specification/hub-backend/client-api). A Hub client uses the Hub Client API for the following * to start a new execution using a target or [sharable token](/technical-specification/hub-backend/sharables) * to submit user input and resume the execution * to query execution state and current route * to upload files using [File cache](/technical-specification/hub-backend/cache) * to execute route functions ## Component repository The Hub DSL scripts are stored in a **Component repository** as [Hub Components](/technical-specification/hub-backend/components) with the support for **versioning**. A **component model** is employed to facilitate reusability, testability and configurability of Hub components, enabling a development model where new components are built from existing ones. The **Admin API** makes it possible to register, query and validate Hub components on-the-fly. This enables making changes without the need to rebuild and redeploy the Hub. ## Storage and Configuration Layer The Hub uses a **cloud-agnostic storage and configuration layer** that supports multiple cloud providers through a pluggable architecture. Component definitions, configurations, API keys, and sharable tokens are stored using provider-specific implementations behind a common abstraction layer defined in `cloud-provider-api`. **Supported Providers:** * **AWS** - Using DynamoDB for storage and Secrets Manager for configuration management * **Local** - In-memory storage for development and testing * Future support planned for Azure and GCP The abstraction layer provides: * **Component Storage** - Versioned component definitions with optimistic locking * **Configuration Management** - Secure storage of component configurations and secrets * **API Key Storage** - Component API key management with permissions * **Sharable Token Storage** - Time-limited tokens for workflow initiation with automatic expiration This architecture allows the Hub to be deployed across different cloud environments or on-premises infrastructure without modifying the core business logic. The provider selection is controlled via configuration, enabling seamless migration between providers. More details can be found in the [Cloud Provider Documentation](/technical-specification/hub-backend/cloud-providers). ## Connector exchanges Connectors are the integration points of the entire workflow orchestration. They are wrapped by exchange commands used within the DSL. Throughout the workflow execution, external/internal providers can be called by means of exchanges that trigger the connectors. The connectors fetch results and decide in each step what to do with the provider responses accordingly. * Exchange processor * processes connector requests * handles connector failures using retries with different retry strategies and timeouts * produces execution requests with connector responses * connectors with reactive interface ## Monitoring The Zenoo Hub employs [Micrometer](https://micrometer.io/)—a vendor-neutral application metrics facade—to integrate with the most popular monitoring systems. Micrometer has a built-in support for AppOptics, Azure Monitor, Netflix Atlas, CloudWatch, Datadog, Dynatrace, Elastic, Ganglia, Graphite, Humio, Influx/Telegraf, JMX, KairosDB, New Relic, Prometheus, SignalFx, Google Stackdriver, StatsD, and Wavefront. More details can be found [here](/technical-specification/hub-backend/metrics).