---
isPrivate: true
title: (LEGACY) Best Practices for OPW Aggregator Architecture
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Observability Pipelines > (LEGACY) Observability Pipelines
  Documentation > (LEGACY) Best Practices for OPW Aggregator Architecture
---

# (LEGACY) Best Practices for OPW Aggregator Architecture

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}).
{% /alert %}

{% /callout %}

{% alert level="warning" %}
If you upgrade your OP Workers version 1.8 or below to version 2.0 or above, your existing pipelines will break. Do not upgrade your OP Workers if you want to continue using OP Workers version 1.8 or below. If you want to use OP Worker 2.0 or above, you must migrate your OP Worker 1.8 or earlier pipelines to OP Worker 2.x.  Datadog recommends that you update to OP Worker versions 2.0 or above. Upgrading to a major OP Worker version and keeping it updated is the only supported way to get the latest OP Worker functionality, fixes, and security updates.
{% /alert %}

{% alert level="info" %}
This guide is for large-scale production-level deployments.
{% /alert %}

## Overview{% #overview %}

The Observability Pipelines Worker's (OPW) aggregator architecture deploys the Observability Pipelines Worker as a standalone service for centralized data processing and routing:

{% image
   source="https://docs.dd-static.net/images/observability_pipelines/production_deployment_overview/aggregator_role2.bc99d983f092e4491593c5050b6fa9af.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/observability_pipelines/production_deployment_overview/aggregator_role2.bc99d983f092e4491593c5050b6fa9af.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="A diagram showing the network load balancer receiving data from various sources and sending the data to the Observability Pipelines Worker aggregator, which has multiple Workers in different availability zones and sends data to various sinks" /%}

Deploy Observability Pipelines Worker into your infrastructure, like any other service to intercept and manipulate data, and then forward it to your destinations. Each Observability Pipelines Worker instance operates independently, so that you can scale the architecture with a simple load balancer.

This guide walks you through the recommended aggregator architecture for new Observability Pipelines Worker users. Specifically, these topics include:

- [Optimizing the instance](https://docs.datadoghq.com/observability_pipelines/legacy/architecture/optimize.md) so you can horizontally scale the Observability Pipelines Worker aggregator.
- Starting points to estimate your resource capacity for [capacity planning and scaling](https://docs.datadoghq.com/observability_pipelines/legacy/architecture/capacity_planning_scaling.md) the Observability Pipelines Worker.
- Determining your [network topology and configurations](https://docs.datadoghq.com/observability_pipelines/legacy/architecture/networking.md) for the Observability Pipelines Worker.
- Achieving [high durability](https://docs.datadoghq.com/observability_pipelines/legacy/architecture/preventing_data_loss.md) and high availability.
- Using the Observability Pipelines Worker as part of your [disaster recovery](https://docs.datadoghq.com/observability_pipelines/legacy/architecture/availability_disaster_recovery.md).
- More [advanced configurations](https://docs.datadoghq.com/observability_pipelines/legacy/architecture/advanced_configurations.md) for deploying multiple aggregators, publish-subscribe systems, and global aggregation.