# 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