diff options
author | Andrew Godwin | 2022-11-19 22:36:54 -0700 |
---|---|---|
committer | Andrew Godwin | 2022-11-19 22:36:54 -0700 |
commit | f9ee3ef69d7e3c91a3df6bad949d25a24baf57b0 (patch) | |
tree | 91d614a0dc01f3493c6866bf1412388cadd851d8 /docs/principles.rst | |
parent | b9bab4c54c2f7c8ea6aaa4a65e348b53349fc7a4 (diff) | |
download | takahe-f9ee3ef69d7e3c91a3df6bad949d25a24baf57b0.tar.gz takahe-f9ee3ef69d7e3c91a3df6bad949d25a24baf57b0.tar.bz2 takahe-f9ee3ef69d7e3c91a3df6bad949d25a24baf57b0.zip |
A bit more docs
Diffstat (limited to 'docs/principles.rst')
-rw-r--r-- | docs/principles.rst | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/docs/principles.rst b/docs/principles.rst new file mode 100644 index 0000000..737c5f9 --- /dev/null +++ b/docs/principles.rst @@ -0,0 +1,59 @@ +Design Principles +================= + +Takahē is somewhat opinionated in its design goals, which are: + +* Simplicity of maintenance and operation +* Multiple domain support +* Asychronous Python core +* Low-JS user interface + +These are explained more below, but it's important to stress the one thing we +are not aiming for - scalability. + +If we wanted to build a system that could handle hundreds of thousands of +accounts on a single server, it would be built very differently - queues +everywhere as the primary communication mechanism, most likely - but we're +not aiming for that. + +Our final design goal is for around 10,000 users to work well, provided you do +some PostgreSQL optimisation. It's likely the design will work beyond that, +but we're not going to put any specific effort towards it. + +After all, if you want to scale in a federated system, you can always launch +more servers. We'd rather work towards the ability to share moderation and +administration workloads across servers rather than have one giant big one. + + +Simplicity Of Maintenance +------------------------- + +It's important that, when running a social networking server, you have as much +time to focus on moderation and looking after your users as you can, rather +than trying to be an SRE. + +To this end, we use our deliberate design aim of "small to medium size" to try +and keep the infrastructure simple - one set of web servers, one set of task +runners, and a PostgreSQL database. + +The task system (which we call Stator) is not based on a task queue, but on +a state machine per type of object - which have retry logic built in. The +system continually examines every object to see if it can progress its state +by performing an action, which is not quite as *efficient* as using a queue, +but recovers much more easily and doesn't get out of sync. + + +Multiple Domain Support +----------------------- + +TODO + + +Asynchronous Python +------------------- + +TODO + + +Low-JS User Interface +--------------------- |