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