---
title: Architecture
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: Docs > BYOC Logs > Introduction to BYOC Logs > Architecture
---

# Architecture

{% callout %}
##### Join the Preview!

BYOC Logs is in Preview.
{% /callout %}

## Overview{% #overview %}

{% image
   source="https://docs.dd-static.net/images/cloudprem/overview_architecture.af8d89bcd0b0b85546dd64ac1fb6fa0e.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/cloudprem/overview_architecture.af8d89bcd0b0b85546dd64ac1fb6fa0e.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="BYOC Logs architecture showing Indexers, Searchers, Metastore, and Control Plane components interacting with object storage" /%}

BYOC Logs uses a decoupled architecture which separates the compute (indexing and searching) and data on an object storage. This allows for independent scaling and optimization of different cluster components based on workload demands.

## Components{% #components %}

The BYOC Logs cluster, typically deployed on Kubernetes (EKS), consists of several components:

{% dl %}

{% dt %}
**Indexers**
{% /dt %}

{% dd %}
Responsible for receiving logs from Datadog Agents. Indexers process, index, and store logs in index files called *splits* to the object storage (for example, Amazon S3).
{% /dd %}

{% dt %}
**Searchers**
{% /dt %}

{% dd %}
Handle search queries from the Datadog UI, reading metadata from Metastore and fetching data from the object storage.
{% /dd %}

{% dt %}
**Metastore**
{% /dt %}

{% dd %}
Stores metadata about the indexes, including split locations on the object storage. BYOC Logs uses PostgreSQL for this purpose.
{% /dd %}

{% dt %}
**Control Plane**
{% /dt %}

{% dd %}
Schedules indexing jobs called *indexing pipelines* on indexers.
{% /dd %}

{% dt %}
**Janitor**
{% /dt %}

{% dd %}
Performs maintenance tasks, applying retention policies, garbage collecting expired splits, and running delete query jobs.
{% /dd %}

{% /dl %}

## Data flow{% #data-flow %}

### Ingestion path (logs entering BYOC Logs){% #ingestion-path-logs-entering-byoc-logs %}

Logs are ingested into BYOC Logs within your infrastructure. The typical flow is:

1. Your applications emit logs to the **Datadog Agent** or **Observability Pipelines Worker**.
1. Logs are forwarded to BYOC Logs **indexers** running in your cluster.
1. Indexers process and store logs as splits in your **object storage** (for example, Amazon S3 or Google Cloud Storage).

**No log data leaves your environment during ingestion.** Logs are stored exclusively in your own object storage.

### Query path (searching logs from Datadog UI){% #query-path-searching-logs-from-datadog-ui %}

When you search BYOC Logs data from the Datadog UI (for example, in the Log Explorer), the query flows through a secure connection between Datadog and your cluster:

1. The Datadog UI sends the search query to Datadog's backend.
1. Datadog's backend forwards the query to your BYOC Logs cluster through the established connection (reverse connection or ingress).
1. **Searchers** in your cluster execute the query against your object storage.
1. Only the **matching log results** are sent back to Datadog for display in the UI.

**Only query results travel between your cluster and Datadog.** The full dataset remains in your object storage and is never transferred to Datadog.

## Connection to Datadog UI{% #connection-to-datadog-ui %}

There are two ways to connect the Datadog UI to BYOC Logs:

- [**Reverse connection**](https://docs.datadoghq.com/byoc-logs/introduction/network.md): Let BYOC Logs initiate bi-directional gRPC requests to Datadog.
- [**Accept external requests from Datadog**](https://docs.datadoghq.com/byoc-logs/configure/ingress.md): Provide Datadog with a DNS endpoint for gRPC requests and configure a public Ingress to accept those requests.

## Further reading{% #further-reading %}

- [BYOC Logs Installation Prerequisites](https://docs.datadoghq.com/byoc-logs/install.md)