#C01AHCD885S Why Airbyte Sync launches multiple pod in Kubernetes?

Airbyte launches multiple pods in Kubernetes for each sync job to handle different aspects of the data integration process efficiently. Here's why: 1. Each concurrent sync requires at least 3 additional connector pods: - Orchestrator pod - Read (source) pod - Write (destination) pod This architecture allows Airbyte to separate concerns and scale different components independently [Documentation > Enterprise-setup > Scaling Airbyte After Installation > Concurrent Syncs](https://docs.airbyte.com/enterprise-setup/scaling-airbyte#concurrent-syncs). 2. The container orchestrator decouples the worker and job processes, which improves resource utilization and scalability [Clarification Needed on Airbyte Job Parallelism and Worker Roles in GKE Deployment > Official answer](https://github.com/airbytehq/airbyte/discussions/42439). 3. In addition to these main pods, Airbyte may also create pods for specific tasks such as: - Check pods (for connection testing) - Discovery pods (for schema discovery) [Clarification Needed on Airbyte Job Parallelism and Worker Roles in GKE Deployment Part 1](https://github.com/airbytehq/airbyte/discussions/42439) 4. This pod-based architecture allows Airbyte to run multiple syncs concurrently and scale horizontally. As a rule of thumb, Kubernetes clusters should be able to accommodate up to

2 x <number-of-possible-concurrent-connections>

pods at once [Documentation > Operator-guides > Scaling Airbyte > What To Scale > On Kubernetes](https://docs.airbyte.com/operator-guides/scaling-airbyte#on-kubernetes). By launching multiple pods, Airbyte can efficiently manage resources, improve fault tolerance, and scale its operations in a Kubernetes environment.