Está haciendo malabarismos con varias API complejas para su aplicación. ¿Cómo se puede garantizar un rendimiento de primer nivel?

In developing a data aggregation platform, our team faced a performance crisis due to simultaneous requests across different APIs, leading to delays and timeouts. By batching API calls, our system streamlined processes by grouping requests into single calls. This technique significantly reduced latency and server load, enhancing overall performance. Instead of incessantly polling APIs for updates, we configured them to push data to our servers using Webhooks as soon as changes occurred. This real-time data transfer eliminated unnecessary queries. Our app not only delivered faster results but also reduced API costs and server strain significantly.

Batching involves combining API calls into a single request reducing the number of round-trips between your application and the server. This technique can significantly improve performance, especially when the latency of individual requests is a concern. Here’s a detailed explanation of how to implement and benefit: Why Batch Requests? 1.𝐑𝐞𝐝𝐮𝐜𝐞 𝐋𝐚𝐭𝐞𝐧𝐜𝐲 2.𝐋𝐨𝐰𝐞𝐫 𝐎𝐯𝐞𝐫𝐡𝐞𝐚𝐝 3.𝐄𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐔𝐭𝐢𝐥𝐢𝐬𝐚𝐭𝐢𝐨𝐧 How To Implement? 1.𝐔𝐬𝐢𝐧𝐠 𝐆𝐫𝐚𝐩𝐡𝐐𝐋 2.𝐑𝐄𝐒𝐓 𝐀𝐏𝐈 𝐰𝐢𝐭𝐡 𝐁𝐚𝐭𝐜𝐡 𝐒𝐮𝐩𝐩𝐨𝐫𝐭 3.𝐌𝐚𝐧𝐮𝐚𝐥 𝐁𝐚𝐭𝐜𝐡𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 𝐚 𝐂𝐮𝐬𝐭𝐨𝐦 𝐄𝐧𝐝𝐩𝐨𝐢𝐧𝐭 Considerations 1.𝐀𝐏𝐈 𝐒𝐮𝐩𝐩𝐨𝐫𝐭 2.𝐏𝐚𝐲𝐥𝐨𝐚𝐝 𝐒𝐢𝐳𝐞 3.𝐄𝐫𝐫𝐨𝐫 𝐇𝐚𝐧𝐝𝐥𝐢𝐧𝐠 4.𝐓𝐢𝐦𝐞𝐨𝐮𝐭𝐬

Caching is a technique used to store copies of frequently accessed data in a temporary storage location, or cache, to reduce the time and resources required to fetch this data repeatedly. Effective caching can significantly improve the performance, scalability, and responsiveness. Caching can be implemented in different ways: 𝐂𝐥𝐢𝐞𝐧𝐭-𝐬𝐢𝐝𝐞 𝐂𝐚𝐜𝐡𝐢𝐧𝐠 𝐒𝐞𝐫𝐯𝐞𝐫-𝐬𝐢𝐝𝐞 𝐂𝐚𝐜𝐡𝐢𝐧𝐠 𝐏𝐫𝐨𝐱𝐲 𝐂𝐚𝐜𝐡𝐢𝐧𝐠 𝐂𝐃𝐍 𝐂𝐚𝐜𝐡𝐢𝐧𝐠 In web applications, Client-side Caching is mostly used to store data on the user's device to reduce the number of API calls sent to the server. This includes using 𝐁𝐫𝐨𝐰𝐬𝐞𝐫 𝐂𝐚𝐜𝐡𝐞 and 𝐋𝐨𝐜𝐚𝐥/𝐒𝐞𝐬𝐬𝐢𝐨𝐧 𝐒𝐭𝐨𝐫𝐚𝐠𝐞 to store the most frequently accessed data.

Problem: Slow response times and frequent API rate limit hits in a financial dashboard application that aggregated data from various banking, investment, and accounting APIs. Solution: Implemented a multi-layered caching strategy: Level 1: In-memory cache (e.g., Guava Cache or Caffeine) for frequently accessed data. Level 2: Distributed cache (e.g., Redis or Memcached) for less frequently accessed data. Cache Expiration: Set appropriate time-to-live (TTL) values based on data freshness requirements. Short TTLs for stock prices, exchange rates. Longer TTLs for static data like user profiles and account information. Result: Improved responsiveness, reduced API load, and better user experience.

Our team owns enterprise billing and it involves a bunch of microservices and bots. One thing we observed recently in one of the microservice is that some user flows were taking longer than expected. After drilling down it was found that in one api we were making too many DB calls. Some of that data was static and could be easily cached. So we configured our microservice to use Redis cache and set a longer TTL so that these IO calls can be reduced. We further implemented a customized caching which could handle static data (which does not change often) and dynamic data (which has a shorter TTL). This not only took care of caching static data for that api but also made service more efficient overall.

Challenge: Real-time financial dashboard with data from various APIs. Solution: Implemented asynchronous processing: o Offloaded long-running API calls to a separate thread pool. o Introduced a message queue system - Apache Kafka. o Decoupled API calls from the main application flow. Benefits: o Improved responsiveness for users. o Evenly distributed load on APIs. o Effective error handling and retries.

This is likely an issue when you’re implementing BFF pattern / api. In this case multiple solutions can be provided- 1. Use asynchronous pattern at the api level like Task-based Asynchronous Pattern (TAP) or Event-based Asynchronous Pattern (EAP) depending on the case you’re handling. 2. You can also implement strategy pattern where you specify a list of functions, code to walk through them, check results and record error if any. This gets complicated when certain api calls depend on data of previous api call. You could use C# - WhenAll / WhenAny constructs to manage the dependency. I feel solution depends upon the use case / nature of the problem

We recently implemented OTEL support to our .Net core apis which basically record custom metrics to NewRelic. You can use middleware to record common metrics or can have metrics logged in specific cases (depending on the use case). In NewRelic we implemented alerts for these custom metrics that can send either a slack notification or email notification. This included some alerts which were triggered after a threshold reached (I/O call times increase) which made us take some decisive actions proactively.

This episode taught me the essence of proactive API monitoring. It's not just about tracking metrics; it's about preempting issues to uphold user experience. By staying vigilant and informed, we ensure seamless performance even amidst complexity.

Optimizing API calls when dealing with multiple complex APIs involves several strategies to enhance efficiency, reduce latency, and ensure smooth operation. The other key points to consider are: 𝐑𝐚𝐭𝐞 𝐋𝐢𝐦𝐢𝐭𝐢𝐧𝐠 𝐚𝐧𝐝 𝐓𝐡𝐫𝐨𝐭𝐭𝐥𝐢𝐧𝐠 𝐑𝐞𝐭𝐫𝐲 𝐋𝐨𝐠𝐢𝐜 𝐚𝐧𝐝 𝐄𝐱𝐩𝐨𝐧𝐞𝐧𝐭𝐢𝐚𝐥 𝐁𝐚𝐜𝐤𝐨𝐟𝐟 𝐂𝐨𝐦𝐩𝐫𝐞𝐬𝐬𝐢𝐨𝐧 𝐏𝐚𝐠𝐢𝐧𝐚𝐭𝐢𝐨𝐧 𝐒𝐞𝐥𝐞𝐜𝐭𝐢𝐯𝐞 𝐃𝐚𝐭𝐚 𝐅𝐞𝐭𝐜𝐡𝐢𝐧𝐠 (𝐅𝐢𝐞𝐥𝐝𝐬 𝐅𝐢𝐥𝐭𝐞𝐫𝐢𝐧𝐠) 𝐋𝐨𝐚𝐝 𝐁𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠 𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐂𝐨𝐧𝐬𝐢𝐝𝐞𝐫𝐚𝐭𝐢𝐨𝐧𝐬 By implementing the techniques above as well as the ones mentioned in this article, you can optimize your API calls, improving the performance and reliability of your application.