docs: Adding some content about the push vs pull model (feast-dev#4385)

* docs: Adding some content about the push vs pull model

Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>

* checking in progress...all of this was mostly autogenerated

Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>

* updated

Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>

* Update push-vs-pull-model.md

* Update push-vs-pull-model.md

* Update push-vs-pull-model.md

---------

Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>

Author: franciscojavierarceo

docs/README.md

@@ -6,7 +6,7 @@ Feast (**Fea**ture **St**ore) is a customizable operational data system that re-
 
 Feast allows ML platform teams to:
 
-* **Make features consistently available for training and serving** by managing an _offline store_ (to process historical data for scale-out batch scoring or model training), a low-latency _online store_ (to power real-time prediction)_,_ and a battle-tested _feature server_ (to serve pre-computed features online).
+* **Make features consistently available for training and low-latency serving** by managing an _offline store_ (to process historical data for scale-out batch scoring or model training), a low-latency _online store_ (to power real-time prediction)_,_ and a battle-tested _feature server_ (to serve pre-computed features online).
 * **Avoid data leakage** by generating point-in-time correct feature sets so data scientists can focus on feature engineering rather than debugging error-prone dataset joining logic. This ensure that future feature values do not leak to models during training.
 * **Decouple ML from data infrastructure** by providing a single data access layer that abstracts feature storage from feature retrieval, ensuring models remain portable as you move from training models to serving models, from batch models to realtime models, and from one data infra system to another.
 
@@ -16,6 +16,16 @@ Feast allows ML platform teams to:
 
 ![](assets/feast_marchitecture.png)
 
+{% hint style="info" %}
+**Note:** Feast uses a push model for online serving. This means that the feature store pushes feature values to the 
+online store, which reduces the latency of feature retrieval. This is more efficient than a pull model, where the model 
+serving system must make a request to the feature store to retrieve feature values. See 
+[this document](getting-started/architecture-and-components/push-vs-pull-model.md) for a more detailed discussion.
+{% endhint %}
+
+{% hint style="info" %}
+{% endhint %}
+
 ## Who is Feast for?
 
 Feast helps ML platform teams with DevOps experience productionize real-time models. Feast can also help these teams build towards a feature platform that improves collaboration between engineers and data scientists.

docs/SUMMARY.md

@@ -20,6 +20,7 @@
 * [Architecture](getting-started/architecture-and-components/README.md)
   * [Overview](getting-started/architecture-and-components/overview.md)
   * [Language](getting-started/architecture-and-components/language.md)
+  * [Push vs Pull Model](getting-started/architecture-and-components/push-vs-pull-model.md)
   * [Registry](getting-started/architecture-and-components/registry.md)
   * [Offline store](getting-started/architecture-and-components/offline-store.md)
   * [Online store](getting-started/architecture-and-components/online-store.md)

docs/getting-started/architecture-and-components/README.md

@@ -8,6 +8,10 @@
 [overview.md](overview.md)
 {% endcontent-ref %}
 
+{% content-ref url="push-vs-pull-model.md" %}
+[push-vs-pull-model.md](push-vs-pull-model.md)
+{% endcontent-ref %}
+
 {% content-ref url="registry.md" %}
 [registry.md](registry.md)
 {% endcontent-ref %}

docs/getting-started/architecture-and-components/push-vs-pull-model.md

@@ -0,0 +1,20 @@
+# Push vs Pull Model
+
+Feast uses a [Push Model](https://en.wikipedia.org/wiki/Push_technology), i.e., 
+Data Producers push data to the feature store and Feast stores the feature values 
+in the online store, to serve features in real-time. 
+
+In a [Pull Model](https://en.wikipedia.org/wiki/Pull_technology), Feast would 
+pull data from the data producers at request time and store the feature values in 
+the online store before serving them (storing them would actually be unneccessary). 
+This approach would incur additional network latency as Feast would need to orchestrate 
+a request to each data producer, which would mean the latency would be at least as long as 
+your slowest call. So, in order to serve features as fast as possible, we push data to 
+Feast and store the feature values in the online store.
+
+The trade-off with the Push Model is that strong consistency is not gauranteed out 
+of the box. Instead, stong consistency has to be explicitly designed for in orchestrating 
+the updates to Feast and the client usage.
+
+The significant advantage with this approach is that Feast is read-optimized for low-latency 
+feature retrieval.