aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBrandon <brandon.wofford@unity3d.com>2022-05-25 11:17:02 -0500
committerGitHub <noreply@github.com>2022-05-25 17:17:02 +0100
commit015465d4966ac69eed09e1d14343078bb5fe083f (patch)
treea2054563c82a7934843076196bb69e6e38821d8c
parent6940c7c7dd9cefc3f7fa0bec00926e96ee669b56 (diff)
Update 1_planning.md (#2467)
* Update 1_planning.md Modes section of the planning component of the documentation rewritten for grammar and clarity. * Update 1_planning.md Co-authored-by: Neil Alexander <neilalexander@users.noreply.github.com>
-rw-r--r--docs/installation/1_planning.md22
1 files changed, 10 insertions, 12 deletions
diff --git a/docs/installation/1_planning.md b/docs/installation/1_planning.md
index 89cc5b4a..45012d80 100644
--- a/docs/installation/1_planning.md
+++ b/docs/installation/1_planning.md
@@ -9,21 +9,19 @@ permalink: /installation/planning
## Modes
-Dendrite can be run in one of two configurations:
+Dendrite consists of several components, each responsible for a different aspect of the Matrix protocol.
+Users can run Dendrite in one of two modes which dictate how these components are executed and communicate.
-* **Monolith mode**: All components run in the same process. In this mode,
- it is possible to run an in-process NATS Server instead of running a standalone deployment.
- This will usually be the preferred model for low-to-mid volume deployments, providing the best
- balance between performance and resource usage.
+* **Monolith mode** runs all components in a single process. Components communicate through an internal NATS
+ server with generally low overhead. This mode dramatically simplifies deployment complexity and offers the
+ best balance between performance and resource usage for low-to-mid volume deployments.
-* **Polylith mode**: A cluster of individual components running in their own processes, dealing
- with different aspects of the Matrix protocol. Components communicate with each other using
- internal HTTP APIs and NATS Server. This will almost certainly be the preferred model for very
- large deployments but scalability comes with a cost. API calls are expensive and therefore a
- polylith deployment may end up using disproportionately more resources for a smaller number of
- users compared to a monolith deployment.
+* **Polylith mode** runs all components in isolated processes. Components communicate through an external NATS
+ server and HTTP APIs, which incur considerable overhead. While this mode allows for more granular control of
+ resources dedicated toward individual processes, given the additional communications overhead, it is only
+ necessary for very large deployments.
-At present, we **recommend monolith mode deployments** in all cases.
+Given our current state of development, **we recommend monolith mode** for all deployments.
## Databases