1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
# ard-008: monolith architecture
Satisfied by: task-024, task-025
## 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.
|
