Saurabh Dashora’s Post

5 Must-Know Techniques to Boost API Performance ✅ Caching The idea of caching is simple. Store frequently accessed data in a cache so that you can access it faster when needed. If there’s a cache miss, fetch the data from the database. It’s quite effective actually but cache invalidation and deciding on the caching strategy can be challenging. ✅ Scale-out with Load Balancing If one server instance isn’t enough, you can think of scaling your API to multiple instances. So - where’s the catch? You need to find a way to distribute requests between these multiple instances. Enter Load Balancer. It not only helps with performance but also makes your application more reliable. However, load balancers work best when your application is stateless and easy to scale horizontally. ✅ Async Processing Sometimes, you can’t solve multiple problems together. The best way is to park them for later. With async processing, you can let the clients know that their requests are registered and under process. Then, you process the requests one by one and communicate the results to the client later on. This allows your application server to take a breather and give its best performance. But of course, async processing may not be possible for every requirement. ✅ Pagination If your API returns a large number of records, you need to explore Pagination. Basically, you limit the number of records per request. This improves the response time of your API for the consumer. ✅ Connection Pooling An API often needs to connect to the database to fetch some data. Creating a new connection for each request can degrade performance. It’s a good idea to use connection pooling to set up a pool of database connections that can be reused across requests. This is a subtle aspect but in highly concurrent systems, connection pooling can have a dramatic impact on performance. 👉 So - which other API Performance technique have you seen?

I asked this question to 11 candidates and only 3 managed to answer: “What’s the difference between Session-based authentication and JWTs?” The rest of the candidates just dropped some basic keywords and got things mixed up. But why did I ask this question? Because the candidates mentioned that they implemented Sessions and JWTs in their projects. So it was a good follow-up question to judge whether they knew what they claimed. In this case, the interviewer isn’t usually expecting a perfect answer unless it’s not an API Security Engineer role or something like that. But a basic understanding of these concepts can boost your chances. Here are a few important points that can help you answer this question: ✅ Session-Based Authentication In this approach, you store the session information in a database or session store and give a session ID to the user. For the user, it’s similar to just getting the Ticket ID of their flight. All other details are stored in the airline’s database. Here’s how it works: - The user makes a login request and the frontend app sends the request to the backend server - The backend creates a session using a secret key and stores the data in session storage - Then, the server sends a cookie back to the client with the unique session ID - The user makes a new request to view another page and the browser sends the session id along with it. - The server verifies the user using this ID. ✅ JWT-based Authentication In the JWT-based approach, you don’t store the session information in the session store. The entire information is available within the token. It’s like getting the flight ticket along with all the details available on the ticket but encrypted. Here’s how it works: - The user makes a login request and it goes to the backend server - The backend server verifies the credentials and issues a JWT. The JWT is signed using a private key. No session storage is involved. - The JWT is passed to the browser using a cookie. For every subsequent request, the browser sends the cookie with the JWT - The server verifies the JWT using the secret private key and extracts the user info. ✅ What’s the better approach - Session or JWTs? In a general sense, you can give the favorite answer of every software engineer. “It depends” JWTs offer some cool benefits when compared to sessions such as: - No separate storage - Easier to scale the client and server But JWTs also have some disadvantages: - Invalidating a JWT is not easy. With session, you can simply delete them from the session store. - The data in the JWT can become stale - The JWTs aren’t exactly small when it comes to size Ultimately, the choice depends on the security requirements of your application. If you can confidently explain this much, you are already ahead of many candidates. Of course, there can be several additional follow-up questions. 👉 So - what other points do you think can be added to boost a candidate's chances?

What's the secret ingredient to service integration in a distributed system? It's choosing the right communication pattern for the requirement. Here are 4 must-know service communication patterns: ✅ Request Response with HTTP This is a synchronous pattern. One service sends a request to another and remains blocked until it gets a response or an error. REST is the most popular architectural style for this pattern. However, the pattern has one pitfall. If you have a chain of service calls (A to B to C to D), one weak link in the chain can fail the entire operation. Not a great experience for the user as well as the developer. ✅ Common Data This pattern flies under the radar despite being heavily used, probably because it’s not a direct communication approach. One service writes data to a specific location (for example, S3 bucket), and another service reads and processes the data. The pattern is great for integrating modern systems with legacy systems having compatibility issues. However, it’s not suitable for low latency requirements. ✅ Async Request Response The request-response approach need not always be synchronous. You can implement the same in an async non-blocking manner. Message queues are ideal to implement this pattern. The challenge is to handle the correlation between request and response. The service instance that sent the request may not be the same as the instance receiving the response. Therefore, you need a way to keep track of requests (a database, perhaps). ✅ Event-Driven Communication In this pattern, a services doesn’t directly talk to another service. It emits an event that other services can consume. Therefore, you need a place where services can send the events and a mechanism by which receiving services can discover the events. Message brokers like RabbitMQ can handle both aspects. This pattern is great for building loosely coupled services. However, it also brings an additional component like the message broker into the mix. 👉 So - which communication pattern have you used?