Description:
Currently, the Event Service is making direct calls to the Friends Service in the GetEventHandler whenever an event is fetched. This process introduces unnecessary latency and potential points of failure, as the entire event retrieval process is dependent on the availability and response time of the Friends Service. This inefficiency affects the performance of the Event Service, especially when handling requests at scale.
Problem:
When the Event Service queries an event, it calls the Friends Service to retrieve the friends data of the user requesting the event. This dependency introduces the following issues:
- Latency: The response time of the
GetEvent query is extended by the need to call the Friends Service.
- Reliability: If the Friends Service is unavailable or experiences high latency, it impacts the Event Service's ability to return the event data in a timely manner.
- Unnecessary Overhead: The Friends Service is called for every
GetEvent request, even when the friends data is not critical for all use cases.
Proposed Solution:
Refactor the Event Service to decouple the Friends Service calls from the GetEvent query:
- Remove Direct Calls: The
GetEventHandler should no longer call the Friends Service when retrieving events.
- Asynchronous Processing: If friend-related data is necessary (e.g., for showing friends who are attending or interested), this data should be fetched asynchronously and separately from the main event details. This can be handled either by a separate request or during the background processing.
- Optional Data: The friends' data (e.g., friends who are signed up or interested in the event) can be retrieved and displayed in a separate request or cached for efficiency, without blocking the main event retrieval.
- Improve Efficiency: The Event Service should focus on efficiently retrieving event data without depending on external services during the
GetEvent query.
Alternatives Considered:
- Caching Friends Data: One alternative was to cache the friends data, but this would add additional complexity in managing cache expiration and synchronization with the actual Friends Service.
- Batch Requests: Another alternative was to batch requests to the Friends Service, but this still introduces unnecessary dependencies and may not fully resolve the performance issue.
Additional Context:
- Events are often queried in high volume, especially in scenarios involving user feeds, where the performance impact is most visible.
- A decoupled solution will allow for more modular services, improving overall system resilience and performance.
Description:
Currently, the Event Service is making direct calls to the Friends Service in the
GetEventHandlerwhenever an event is fetched. This process introduces unnecessary latency and potential points of failure, as the entire event retrieval process is dependent on the availability and response time of the Friends Service. This inefficiency affects the performance of the Event Service, especially when handling requests at scale.Problem:
When the Event Service queries an event, it calls the Friends Service to retrieve the friends data of the user requesting the event. This dependency introduces the following issues:
GetEventquery is extended by the need to call the Friends Service.GetEventrequest, even when the friends data is not critical for all use cases.Proposed Solution:
Refactor the Event Service to decouple the Friends Service calls from the
GetEventquery:GetEventHandlershould no longer call the Friends Service when retrieving events.GetEventquery.Alternatives Considered:
Additional Context: