Hello Feast Developers,
I want to implement Feast in my place to unify our features. Currently we have usecase that given 100 product_id, sort from product that will likely clicked by user_id. It means and 1 request will hit Feast Serving API 100 times, and if the usecase RPS is 100 RPS, it means 10.000 RPS in Feast Serving API.
How can we make sure that Feast Serving API can handle all this request? Do Feast have solution to this problem?
Another concern is, can we separate the serving layer per usecase? Let say redis A is used by usecase A and redis B for usecase B. This is to make sure when 1 usecase have increased traffic, it won't affect the other.
Thank you for your answer ^^
Feast is already capable of supporting this use case. Each retrieval request to the online serving API can take a collection of entities, meaning you can send a list of products or users, or both. Feast will enrich those entities with feature values and respond.
Feast, however, does not currently support wildcard queries. You need to provide all entities, and Feast will look up the appropriate features.
In terms of having a serving layer per use case: That's totally possible. How most teams do this is to have a single repository for feature definitions, but have different Feast serving deployments (online store) for each use case and production system.