feat: Updated Feast model Inference Architecture

[franciscojavierarceo]

What this PR does / why we need it:

This PR updates the documentation to provide a diagram of how an ML Platform can work with Feast.

Which issue(s) this PR fixes:

#4455

Misc

[HaoXuAI]

Looks good.
I think the application -> online store can also be async write, just not supported yet.
That's something I think we can explore more, as it gives user more flexibility to write to feast directly.

[franciscojavierarceo]

Looks good. I think the application -> online store can also be async write, just not supported yet. That's something I think we can explore more, as it gives user more flexibility to write to feast directly.

I actually covered some of that in the new architecture section under Communication Patterns.

Communication Patterns

There are two ways a client (or Data Producer) can send data to the online store:

1. Synchronously

• Using a synchronous API call for a small number of entities or a single entity (e.g., using the push or write_to_online_store methods) or the Feature Server's push endpoint)

2. Asynchronously

• Using an asynchronous API call for a small number of entities or a single entity (e.g., using the push or write_to_online_store methods) or the Feature Server's push endpoint)
• Using a "batch job" for a large number of entities (e.g., using a batch materialization engine)

Note, in some contexts, developers may "batch" a group of entities together and write them to the online store in a single API call. This is a common pattern when writing data to the online store to reduce write loads but we would not qualify this as a batch job.

Let me know if you think I should add some info there. In general, if users are going to do an async write, I think that has different tradeoffs that we want people to be thoughtful about, which is what I tried to say more broadly in that Write Patterns architecture document.