Tech With Rahul

Continuing our journey of the HTTP series, the previous part explored into the progression of HTTP leading up to HTTP/1.1. In this segment, we will begin by examining certain limitations of HTTP/1.1, and subsequently, delve into the intricacies of HTTP/2.0, which looks to overcome these limitations. Limitations of HTTP/1.1 that lead to HTTP/2.0: Head-of-Line Blocking: In HTTP/1.1, multiple HTTP requests are transmitted over a single TCP connection. However, the caveat is that they are sent sequentially. In other words, the next HTTP request cannot be sent until the response to the current HTTP request is received. If getting one of the resources is delayed, subsequent resources are also blocked, even if they are independent and could be fetched more quickly. Limited Multiplexing: The sequential execution of HTTP requests over a TCP connection introduces latency, especially when fetching numerous resources. To mitigate this, modern browsers employ a workaround, allowing a maximum of 6 ...

Hypertext Transfer Protocol (HTTP) enables the transfer of data over the Internet. HTTP is an application-layer protocol that facilitates the transmission of hypermedia documents, such as HTML. It was designed for communication between web browsers and servers but can also be used for other purposes. I have discussed in detail about different  modes of communication between a client and a server. They all use HTTP under the hood. HTTP is a “stateless” protocol, which means each request is executed independently, without any knowledge of the requests that were executed before it. It uses the underlying transport protocol TCP (Transmission Control Protocol) to establish and manage connections between a client and a server.  Transmission Control Protocol (TCP): TCP is a connection-oriented transport layer protocol. It provides a fully duplex and reliable exchange of messages between different devices over a network. Some of the main features of TCP are: Reliability: TCP ens...

Choosing the right database in the system design interviews is one of the most important decisions. The database selection impacts the design correctness and scalability of the system. There are many factors which might impact the decisions, but the most important ones are: Structure of the Data: Different databases support data models such as relational, document, key-value, graph, etc. The choice of database depends on which data model best fits the structure of your data. For example, a traditional relational database like MySQL or PostgreSQL might be appropriate if the data is highly structured and relational. A NoSQL database like Cassandra or MongoDB might be more suitable if the data is semi-structured or unstructured. Query Pattern: Understanding the types of queries and operations performed on the data helps select a database that can efficiently handle those operations. Are they read-heavy or write-heavy? Do they involve complex joins, aggregations, or full-text searches?...

A Merkle Tree is a cryptographic tree structure used in computer science and distributed systems to efficiently verify the integrity of large sets of data (accuracy and consistency of data over its lifecycle).  Merkle Tree, also known as Hash Tree is a tree of hash values.  It has a tree structure in which each leaf node is a hash of a small portion of the data, and each non-leaf node is a hash of its children. It is used in applications such as  NoSQL databases, Git, Cryptocurrencies,  File Systems, etc. Some key characteristics of Merkle Tree are: Binary Tree Structure:  The Merkle Tree is a binary tree, where each leaf node represents a hash of data. Leaf Nodes: The data set is divided into fixed-size blocks or "leaves". Each leaf node contains the hash of a specific data block or piece of information. Non-Leaf Nodes: Non-leaf nodes in the tree represent the hash of the concatenation of their child node's hashes.  If the number of leaves is odd...

A Bloom filter is a space-efficient probabilistic data structure used to determine whether an element is a member of a set. The filter responds to queries with either a definite No or a probable Yes. The probabilistic nature of the Bloom filter is apparent in its ' probably Yes ' responses. This implies the possibility of false positives. When the Bloom filter indicates Yes, the element might or might not be present in the set. However, if the Bloom filter returns No, then the element is definitively not present in the set. Software engineering is all about tradeoffs. When using the Bloom filter, we sacrifice a bit of accuracy and flexibility to gain a substantial boost in performance. The key consideration is identifying use cases where it's acceptable to detect an element in the set, even if it's not actually present. Let us understand the core algorithm first then we will see its real life applications: Algorithm: A key element in the construction of a Bloom Filter i...

This is the third and final part of the Client-Server Communication Model. You can have a look at the first and second parts where we discussed different ways in which client and server can communicate. Here, we will focus on one of the most popular communication models: WebSockets. 5. WebSockets WebSockets ( RFC-6455 ) enable real-time, two-way, full-duplex communication between client and server over a single, long-lived connection. WebSocket, like SSE , provides a persistent connection. But in contrast to SSE, it enables full-duplex communication, which means that both client and server can communicate over the same channel. WebSockets are suitable for building interactive and dynamic applications that require continuous communication between clients and servers. It leverages the HTTP protocol for connection establishment. Since HTTP/1.0 is a non-persistent connection, WebSocket can not be implemented on HTTP/1.0. It needs a protocol having a persistent connection, like HTTP/...

This is the second part of the Client-Server Communication Model. You can have a look at the first part  where we discussed Polling, Long Polling, and Webhooks. Here, we will focus on Server-Sent Events. 4. Server-Sent Events (SSE) Server-Sent Events (SSE) are based on server push technology enabling a client to receive automatic updates from a server via an HTTP connection. The clients make a persistent long-lived connection with the server. Then, the server uses this connection to send the data to the client. It is important to note that the client can’t send the data to the server using the SSE. It is a unidirectional way to flow data from the server to the client. The request-response flow of SSE is: The client issues an HTTP GET request to the server, with the request headers Accept: text/event-stream and   Connection: keep-alive . The inclusion of   Accept: text/event-stream  in the request informs the server that the client aims to initiate an SSE co...