docs: add link between sync docs and related architecture docs

Author: f4z3r

docs/architecture/index.rst

@@ -132,6 +132,8 @@ In Kolibri, on the ``FacilityDataset`` model, we generate the certificate as a f
 There's flexibility in the application layer for determining the validity of a root certificate, and it's specified on a per-profile basis. For the ``facilitydata`` profile, Kolibri leverages its ``auth`` models for this.
 
 
+.. _operations:
+
 Session controller, contexts, and operations
 --------------------------------------------
 

docs/syncing/index.rst

@@ -21,7 +21,7 @@ Syncing is the actual exchange of data in a sync session. The general steps for
 4. **Dequeuing** - merging the data received in the receiving buffers to the receiving store and record-max counter. During this step, the data from the incoming buffer is merged into the store on the receiving side. Merge conflicts in case of version splits can be solved automatically. As new data is written into the store, the dirty bit on that object is set to indicate that the data needs to be deserialized and pushed to the Application Layer.
 5. **Deserialization** - merging data from the receiving Store into the Django models in the Application layer. Data marked as stale in the Application Layer (where a newer version is available in the Store, on a record with the dirty bit set), the data in the store is deserialized from JSON into a Django model and integrated into the Application Layer.
 
-The individual steps of the syncing process are implemented in `morango/sync/operations.py <https://github.com/learningequality/morango/blob/HEAD/morango/sync/operations.py>`_. They are implemented as operations that are registered for every process step described above. A project using Morango can define their own operations and register them to be executed as part of an arbitrary step in the process via configuration options such as ``MORANGO_INITIALIZE_OPERATIONS``.
+The individual steps of the syncing process are implemented in `morango/sync/operations.py <https://github.com/learningequality/morango/blob/HEAD/morango/sync/operations.py>`_. They are implemented as operations that are registered for every process step described above. A project using Morango can define their own operations and register them to be executed as part of an arbitrary step in the process via configuration options such as ``MORANGO_INITIALIZE_OPERATIONS``. Details on these operations can be found under `Session controller, contexts, and operations <../architecture#operations>`__
 
 
 In the illustration below, the application layer (on the right) is where app data resides as Django models, and the Morango layer (on the left) is where the Morango stores, counters, and buffers reside. *Instance A* (on the top) is sending data to *Instance B* (on the bottom). Application Django models in *Instance A* are serialized in JSON format and saved to the store. Data is queued in the buffers on *Instance A*, and then transmitted to the corresponding buffers on *Instance B*. The data is then integrated into the store and Django app models on *Instance B*.