Add Synchronisation section

Application-Design.md

@@ -50,3 +50,25 @@ about users anyway. In general it seems to be better to have a strong set of rul
 flexibility which gets implemented by each software in another way, and therefore leads to missing
 interoperability. So if the information about the user is really needed, there should be another
 date field for it.
+
+
+## Synchronisation
+
+There are two uses cases for for what we basically call synchronisation. On the one hand users want
+to be able to access and modify their records from any device in use. On the other hand users might
+be interested in sharing their records, eg with their companies time-tracking system. These are
+different aspects and there need to be different mechanisms to support them both the right way.
+
+Synchronisation is a multilateral process. There are several participating devices. Usually each
+device should be able to modify the records. This leads to the possibility of conflicting changes
+and there needs to be a way to handle them. To avoid overhead there needs to be a way to reduce the
+amount of synchronized data by only updating whats needed, but on the other hand we must not miss
+any changes.
+
+The usecase to push changes to centralized tracking system used eg by your company or send tracked
+records into your issue tracker has other requirements. This is more like an export. There need to be
+service specifiy mappings from tags to whatever meta-data is required by the service (eg projects,
+issue number...). There is probably no need to pull any changes made on these platforms back into
+your system. 
+
+