From 1259fa9eb1595c141fb80a643b8618cc9e4f6db9 Mon Sep 17 00:00:00 2001 From: Christian Mollekopf Date: Mon, 8 Feb 2016 09:57:19 +0100 Subject: Documentation structure --- docs/tradeoffs.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 docs/tradeoffs.md (limited to 'docs/tradeoffs.md') diff --git a/docs/tradeoffs.md b/docs/tradeoffs.md new file mode 100644 index 0000000..d0e32c1 --- /dev/null +++ b/docs/tradeoffs.md @@ -0,0 +1,36 @@ +# Tradeoffs/Design Decisions +* Key-Value store instead of relational + * `+` Schemaless, easier to evolve + * `-` No need to fully normalize the data in order to make it queriable. And without full normalization SQL is not really useful and bad performance wise. + * `-` We need to maintain our own indexes + +* Individual store per resource + * Storage format defined by resource individually + * `-` Each resource needs to define it's own schema + * `+` Resources can adjust storage format to map well on what it has to synchronize + * `+` Synchronization state can directly be embedded into messages + * `+` Individual resources could switch to another store technology + * `+` Easier maintenance + * `+` Resource is only responsible for it's own store and doesn't accidentaly break another resources store + * `-` Inter`-`resource moves are both more complicated and more expensive from a client perspective + * `+` Inter`-`resource moves become simple additions and removals from a resource perspective + * `-` No system`-`wide unique id per message (only resource/id tuple identifies a message uniquely) + * `+` Stores can work fully concurrently (also for writing) + +* Indexes defined and maintained by resources + * `-` Relational queries accross resources are expensive (depending on the query perhaps not even feasible) + * `-` Each resource needs to define it's own set of indexes + * `+` Flexible design as it allows to change indexes on a per resource level + * `+` Indexes can be optimized towards resources main usecases + * `+` Indexes can be shared with the source (IMAP serverside threading) + +* Shared domain types as common interface for client applications + * `-` yet another abstraction layer that requires translation to other layers and maintenance + * `+` decoupling of domain logic from data access + * `+` allows to evolve types according to needs (not coupled to specific application domain types) + +# Risks +* key-value store does not perform with large amounts of data +* query performance is not sufficient +* turnaround time for modifications is too high to feel responsive +* design turns out similarly complex as Akonadi -- cgit v1.2.3