add ard-007, ard-008, edit ard-004, ard-006

1 files changed, 46 insertions, 0 deletions

diff --git a/requirements/architecture/ard-008.md b/requirements/architecture/ard-008.md
new file mode 100644
index 0000000..f728642
--- /dev/null
+++ b/requirements/architecture/ard-008.md
@@ -0,0 +1,46 @@
+# ard-008: monolith architecture
+
+## Problem
+
+The architecture already contains the following software components running
+remotely from the user:
+
+- A CRDT sync server (ard-003)
+- An SQLite file which the CRDT sync server uses to store domain data (ard-006)
+- A backup service (ard-007)
+- A REST API (ard-004)
+- An SMS API (req-031, req-045, req-047, req-053)
+- A Web app server (ass-018)
+
+We need to decide how these components will be distributed across hardware.
+
+## Options
+
+- Microservice architecture
+- Monolith architecture
+- Something in-between
+
+## Decision
+
+Schist must have all the remote components - the CRDT sync server, the SQLite
+file, the backup service, the REST API, the SMS API and the Web app server -
+running on a single machine.
+
+## Discussion
+
+Dividing software components between hardware units is good for applications
+where scalability and resilience are very important. However, Schist is likely
+to be a low-risk application with at most one user, so these features are not
+important.
+
+On the other hand, dividing software components between hardware units is
+complicated to set up and maintain and more expensive to operate.
+
+For that reason, Schist will swing hard in the direction of monolith
+architecture. This will keep things simple, and is appropriate in this low-risk,
+small-scale application.
+
+## Consequences
+
+There must be documented processes for installing, updating and operating the
+software on the server machine.