Finalize architecture documentation
Issue-ID: CPS-447
Signed-off-by: Bruno Sakoto <bruno.sakoto@bell.ca>
Change-Id: I87ef8a9aee216dfc8f54749243d27d5c0b3d3981
diff --git a/docs/content/architecture.rst b/docs/content/architecture.rst
index 18f4cc3..69aafef 100644
--- a/docs/content/architecture.rst
+++ b/docs/content/architecture.rst
@@ -8,6 +8,31 @@
CPS Temporal Architecture
=========================
-.. warning:: Draft
+CPS Temporal is a dedicated service, **distinct** and **decoupled** from CPS
+Core. CPS Temporal service is an **independently deployable** unit.
-* Subsystem and components architecture
+Integration between Core and Temporal is **event notification based,
+asynchronous, send and forget**. By doing this, we are avoiding the dependency
+from CPS Core on CPS Temporal and its API. It reverses the
+dependency, which makes more sense from a conceptual point of view.
+
+For each data modification handled by CPS Core,
+
+* CPS Core is **publishing**, to a dedicated topic, an event representing the
+ data configuration or state.
+* CPS Temporal is **listening** to the same topic for the event and is
+ responsible to keep track of all data over time.
+
+In the future, some other services can be created to listen to the same topic
+to implement additional functionalities or storage forms.
+
+The event messaging system for this integration is **Kafka**, whose running
+instance is deployed independently from CPS. It could be either:
+
+* the ONAP Kafka instance from ONAP DMaaP component,
+* or any specific Kafka instance deployed independently from ONAP
+
+The following diagram is the C4 Model representing CPS System Containers:
+
+.. image:: /_static/images/cps-temporal-c4-container.png
+ :alt: C4 Model Diagram: Containers for CPS Software system