mirror of
https://github.com/jointakahe/takahe.git
synced 2024-11-22 23:30:59 +00:00
60 lines
1.9 KiB
ReStructuredText
60 lines
1.9 KiB
ReStructuredText
|
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
|
||
|
|
---------------------
|