1--- 2last_modified_on: "2020-07-13" 3title: Deployment Topologies 4description: The various topologies that Vector can accomplish and when to use each. 5sidebar_label: Topologies 6--- 7 8import SVG from 'react-inlinesvg'; 9 10In the previous section we covered the various [deployment 11strategies][docs.strategies] used to collect and forward data. You combine these 12strategies to form topologies. This section showcases common topologies and the 13pros and cons of each. Use these as _guidelines_ to build your own. 14 15<!-- 16 THIS FILE IS AUTOGENERATED! 17 18 To make changes please edit the template located at: 19 20 website/docs/setup/deployment/topologies.md.erb 21--> 22 23## Distributed 24 25<SVG src="/img/topologies-distributed.svg" /> 26 27The simplest topology. This topology offers direct communication with your 28downstream services from your client nodes. 29 30### Pros 31 32* **Simple.** Less moving parts. 33* **Elastic.** Easily scales with your app. Resources grow as you scale. 34 35### Cons 36 37* **Less efficient.** Depending on the complexity of your pipelines, this will 38 use more local resources, which could disrupt the performance of other 39 applications on the same host. 40* **Less durable.** Because data is buffered on the host it is more likely 41 you'll lose buffered data in the event of an unrecoverable crash. Often times 42 this is the most important and useful data. 43* **More downstream stress.** Downstream services will receive more requests 44 with smaller payloads that could potentially disrupt stability of these 45 services. 46* **Reduced downstream stability.** You risk overloading downstream services 47 if you need to scale up quickly or exceed the capacity a downstream service 48 can handle. 49* **Lacks multi-host context.** Lacks awareness of other hosts and eliminates 50 the ability to perform operations across hosts, such as reducing logs to 51 global metrics. This is typically a concern for very large deployments where 52 individual host metrics are less useful. 53 54## Centralized 55 56<SVG src="/img/topologies-centralized.svg" /> 57 58A good balance of simplicity, stability, and control. For most, this topology 59is a good compromise between the [distributed](#distributed) and 60[stream-based](#stream-based) topologies. It offers many of the advantages of 61the stream-based topology without the management overhead and cost of running a 62Kafka cluster. 63 64### Pros 65 66* **More efficient.** More efficient for client nodes and downstream services. 67 Vector agents are doing less which means they're using less resources. In 68 addition, the centralized Vector service will buffer more data, achieve 69 better compression, and send optimized requests downstream. 70* **More reliable.** Vector will protect downstream services from volume spikes, 71 buffering and flushing data at smoothed out intervals. 72* **Has multi-host context.** Because your data is centralized, you'll be able 73 to perform operations across hosts, such as reducing logs to global metrics. 74 This is advantageous for large deployments where individual host metrics are 75 not interesting. 76 77### Cons 78 79* **More complex.** There are more moving parts. 80* **Less durable.** Agent nodes are designed to get data off of the machine as 81 quickly as possible, and this offers higher potential for data loss since the 82 central Vector service could die and lose buffered data. If this type of 83 outage is unacceptable, then we recommend the 84 [stream-based topology](#stream-based) below. 85 86## Stream-Based 87 88<SVG src="/img/topologies-stream-based.svg" /> 89 90The most durable and elastic topology. This topology is typically adopted for 91very large streams with teams that are familiar with running a stream-based 92service such as Kafka. 93 94### Pros 95 96* **Most durable & reliable.** Stream services, like Kafka, are designed for 97 high durability and reliability, replicating data across multiple nodes. 98* **Most efficient.** Vector agents are doing less, making them more efficient, 99 and Vector services do not have to worry about durability, which can be tuned 100 towards performance. 101* **Ability to restream.** Restream your data depending on your stream's 102 retention period. 103* **Cleaner separation of responsibilities.** Vector is used solely as a routing 104 layer and is not responsible for durability. Durability is delegated to a 105 purpose-built service that you can switch and evolve over time. 106 107### Cons 108 109* **Increased management overhead.** Managing a stream service, such as Kafka, 110 is a complex endeavor and generally requires an experienced team to setup and 111 manage properly. 112* **More complex.** This topology is complex and requires a deeper understand of 113 managing production-grade streams. 114* **More expensive.** In addition the management cost, the added stream cluster 115 will require more resources which will increase operational cost. 116 117[docs.strategies]: /docs/setup/deployment/strategies/ 118