sink/docs/tradeoffs.md

0001 # Tradeoffs/Design Decisions
0002 * Key-Value store instead of relational
0003     * `+` Schemaless, easier to evolve
0004     * `-` 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.
0005     * `-` We need to maintain our own indexes
0006
0007 * Individual store per resource
0008     * Storage format defined by resource individually
0009         * `-` Each resource needs to define it's own schema
0010         * `+` Resources can adjust storage format to map well on what it has to synchronize
0011         * `+` Synchronization state can directly be embedded into messages
0012     * `+` Individual resources could switch to another store technology
0013     * `+` Easier maintenance
0014     * `+` Resource is only responsible for it's own store and doesn't accidentaly break another resources store
0015     * `-` Inter`-`resource moves are both more complicated and more expensive from a client perspective
0016     * `+` Inter`-`resource moves become simple additions and removals from a resource perspective
0017     * `-` No system`-`wide unique id per message (only resource/id tuple identifies a message uniquely)
0018     * `+` Stores can work fully concurrently (also for writing)
0019
0020 * Indexes defined and maintained by resources
0021     * `-` Relational queries accross resources are expensive (depending on the query perhaps not even feasible)
0022     * `-` Each resource needs to define it's own set of indexes
0023     * `+` Flexible design as it allows to change indexes on a per resource level
0024     * `+` Indexes can be optimized towards resources main usecases
0025     * `+` Indexes can be shared with the source (IMAP serverside threading)
0026
0027 * Shared domain types as common interface for client applications
0028     * `-` yet another abstraction layer that requires translation to other layers and maintenance
0029     * `+` decoupling of domain logic from data access
0030     * `+` allows to evolve types according to needs (not coupled to specific application domain types)
0031
0032 # Risks
0033 * key-value store does not perform with large amounts of data
0034 * query performance is not sufficient
0035 * turnaround time for modifications is too high to feel responsive
0036 * design turns out similarly complex as Akonadi