feat(route): add mrinalxdev blog RSS route #20909
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Successfully generated as following: http://localhost:1200/mrinalxdev/blog - Success ✔️<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
<channel>
<title>Mrinal's Blog</title>
<link>https://mrinalxdev.github.io/mrinalxblogs/blogs/blog.html</link>
<atom:link href="http://localhost:1200/mrinalxdev/blog" rel="self" type="application/rss+xml"></atom:link>
<description>Technical blog by Mrinal covering Redis, Distributed Systems, Algorithms, and more. - Powered by RSSHub</description>
<generator>RSSHub</generator>
<webMaster>contact@rsshub.app (RSSHub)</webMaster>
<language>en</language>
<lastBuildDate>Fri, 16 Jan 2026 17:40:31 GMT</lastBuildDate>
<ttl>5</ttl>
<item>
<title>Redis 101 : From a Beginners POV</title>
<description><hr class="mt-3">
<h1 class="text-4xl mt-[57px] mb-3 font-serif">
Redis 101 : From a Beginners POV
</h1>
<span class="text-sm text-gray-500">2nd October, 2025</span>
<p class="text-lg font-serif mt-4">
Whenever I have talked about redis in my projects people woud think it as a cache to use . But redis is more than that we can use redis as rate limiter, message broker and as a database ... But what is even redis, why is it even so fast and how are we even using it . Raising all this question made me curious about this topic and so I want you to be ...
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/banner.png" class="w-[750px] mx-auto my-10" alt="" referrerpolicy="no-referrer">
<h1 class="text-2xl font-serif">Foundation</h1>
<p class="font-serif mt-4 text-lg">Lets first start with <span class="font-bold">What is Cache</span> so its simple caching is like keeping frequently used items on your desk instead of fetching them from a storage room. Caching stores frequently accessed data in a temporary, high-speed storage layer, reducing latency and improving performance by minimizing redundant computations or database queries. Now Redis is our <span class="font-bold">high speed storage layer</span> stands for remote dictionary server, its a single threaded, in memory data structure storage model .. Which means unlike databases like PostgreSQL, MySQL which stores data on slower mechanical or solid state drives, redis keeps all its data in RAM. This means every read and write operation happens at memory speed wihtout the worrying about disk input / output </p>
<h1 class="text-2xl font-serif my-7">Why Redis is this fast ??</h1>
<p class="font-serif text-lg mt-3">There are three main pillers behind this speed, first being the <span class="font-bold">In Memory Data Storage</span>, this is the most significant factor as accessing data from RAM is orders of magnitude faster than from even the fastest SSDs or NVMe drives. Main memory access latency is typically in the nanosecond range, while disk access is in the microsecond to millisecond range. By keeping the entire dataset in RAM, redis eliminates biggest bottleneck in database systems which is disk I/O</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/ram.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg mt-3">Second reason being <span class="font-bold">Single threaded command execution</span>, redis processes all commands on a single thread. This design avoids the overhead of multithreading. There are no locks to acquire, no context switching between threads and no race conditions to manage. The CPU can focus purely on executing commands sequentially without interruption, which is incredibly efficient for the workload Redis is designed for (many small, fast operations).</p>
<p class="font-serif text-lg mt-3">Third reason being <span class="font-bold">highly optimized C code and data structures</span>, redis is written in ANSI C, a language known for its performance. Beyond the language, it uses custom, highly-tuned data structures. For example, its Simple Dynamic String (SDS) and the various encodings for Hashes and Sets (like ziplists) are designed to minimize memory usage and CPU cycles for common operations, ensuring that not only is the data in RAM, but it's stored in the most efficient way possible.</p>
<p class="text-lg font-serif mt-4">You might get a question that redis must handle thousand of concurrent client connections and execute commands with microsecond latency, what architectural mode allows it to manage this so effieciently??</p>
<h1 class="my-6 text-2xl font-serif">The single threaded nature</h1>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/concurrency/multi-threaded.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">The core of Redis's command processing is single threaded. This means it uses a single CPU core to process all incoming commands, parse them and execute them. This choice is intentional,as it eliminates the complexity and performance overhead of multithreading, such as lock contention, race condition and context switching</p>
<p class="text-lg font-serif mt-3">To handle concurrency, redis employes an event driven architecture using an <span class="font-bold">I/O multiplexing</span> mechanism. The main thread runs an event loop that uses system calls epoll, kqueue or IOCP to effieciently observe multiple network sockets</p>
<p class="text-lg font-serif mt-3">Lets take up a scene in which you are the only one who knows how to cook and chop veggies, but you can only chop one ingredient at a time(the single redis thread). But you have multiple assistants (your friends ofc) (the operating system's I/0 multiplexing features, like kqueue and IOCP). You told your friends to watch all these pots on the stove. The moment one is ready, they should inform you. All this to not waste your time standing and string at the pots. Instead you chop veggies, when one of your assistant shouts, "pot#3 is boiling !!" then you immediately stop what ever was being done, deal with that pot and then go back to chopping. So in this scenario <span class="font-bold">you</span> are the redis main event loop, <span class="font-bold">pots</span> are client connections and <span class="font-bold">your friends</span> are the operating system's kernel, which efficiently notifies Redis when a client has sent a request or is ready to receive a response.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/io.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">So this is what the actual process looks like : </p>
<ul class="font-serif text-lg list-disc ml-6 my-4">
<li>The event loop registers all client sockets with the multiplexing API.</li>
<li>The API notifies the Redis event loop only when a socket is ready for an I/O operation (e.g., a client has sent data, or a TCP buffer is ready to receive a response).</li>
<li>The single thread then processes the ready event: it reads the command from the socket, parses it, executes it, and writes the response back to the socket.</li>
</ul>
<p class="text-lg font-serif mt-3">This non-blocking I/O model ensures the single thread is never idle waiting for network or disk operations. It is always busy processing events, which is how it achieves high throughput and concurrency with a single thread.</p>
<p class="text-lg font-serif mt-3">As a engineer you should get this question, that Redis's primary storage is volatile RAM. What mechanisms does it provide to ensure data persistence and durability, allowing it to recover from server restarts or crashes? </p>
<h1 class="my-6 text-2xl font-serif">Lets talk about Persistance</h1>
<p class="font-serif text-lg mt-3">Redis provides two distinct, complementary persistence mechanisms to save the in-memory dataset to non-volatile storage.</p>
<ul class="font-serif text-lg list-disc ml-6 my-4">
<li>RDB (Redis Database): This persistence method creates point-in-time snapshots of the dataset. It works by forking a child process, as described previously. The child process writes the entire dataset to a single, compact, binary .rdb file on disk. This is efficient in terms of CPU and I/O. The main advantage is that the resulting file is perfect for backups and allows for fast data restoration on restart. The primary disadvantage is the potential for data loss: if the server crashes between two configured snapshots, all writes since the last snapshot are lost.</li>
<li>AOF (Append Only File): This method logs every write operation command that modifies the dataset. These commands are appended to an appendonly.aof file. Upon restart, Redis re-executes these commands in sequence to reconstruct the original dataset. Durability is controlled by the appendfsync configuration:
<ul class="ml-4 list-decimal">
<li>always: Syncs after every write. Slowest but safest.</li>
<li>everysec: Syncs once per second. The recommended default, providing a good balance of speed and safety (max 1 second of data loss).</li>
<li>no: Lets the OS decide when to flush. Fastest but least safe.</li>
</ul>
</li>
</ul>
<p class="font-serif text-lg mt-3">To prevent the AOF file from growing indefinitely, Redis can automatically rewrite it in the background. It forks a child process that writes the minimal set of commands needed to recreate the current dataset into a new, temporary AOF file, which is then atomically swapped with the old one.</p>
<p class="font-serif text-lg mt-3">For maximum durability, it is common practice to use both AOF for near-real-time persistence and RDB for periodic backups.</p>
<p class="font-serif text-lg mt-3">Lets take a some good use cases of redis in production grade application</p>
<p class="font-serif text-lg mt-3">First which is commonly known and used by every developers and engineers out there, <span class="font-bold">Redis as cache layer</span>.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets//redis/basic-sys.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg mt-3">Lets say you have a web application where users frequently view their profiles fetching this data from a disk based database like MySQL everytime can be slow instead we can use redis to cache the user profile data so when a user requests their profile the application first checks redis, if the desired data is in redis it's a <span class="font-bold">cache hit</span> it is returned immediately, if the data is not in redis it's a <span class="font-bold">cache miss</span> the cache miss the application fetches it from the primary database stores it in redis and then returns it to the user. The data in redis can have <span class="font-bold">TTL</span> or <span class="font-bold">Time To Live</span> so it can automatically expire after a certain time for example say 15 to 20 minutes to ensure fresh is there all the time.</p>
<p class="font-serif text-lg mt-3">Second scenario is using <span class="font-bold">Redis as Database</span> specially for use cases where speed and low latency are very much important, just like building a gaming application.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/rdb.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">Here we need to maintain a realtime leaderboard where player scores are constantly updated and we need to display the top 10 players instantly. So here we can use redis as sorted set data structure to store player scores, each player score is added to the sorted set with their ID as the key and the score as the value this automatically sorts the scores so we can quickly retrieve the top 10 players using a single command like <span class="font-bold">ZREVRANGE leaderboard 0 9</span>. Redis can then process this data to disk using RDB or AOF to ensure durability. </p>
<p class="text-lg font-serif mt-4">What internal data structures and optimizations allow it to store complex data types with minimal overhead?</p>
<h1 class="text-2xl font-serif my-7">Memory Management</h1>
<p class="font-serif text-lg">Redis's memory efficiency stems from its use of custom, highly-optimized data structures and dynamic encoding strategies.</p>
<ul class="text-lg font-serif mt-4 ml-4 list-disc">
<li> Redis does not use standard C-style null-terminated strings. Instead, it uses its own SDS structure. An SDS <span class="font-bold">(Simple Dynamic String)</span> is a struct that contains metadata (like the length of the string and the total allocated memory) followed by a byte array holding the actual data. This design provides several advantages which are</li>
<ul>
<li>O(1) Length Lookup: The length is stored directly in the struct, avoiding the need to scan the entire string.</li>
<li>When an SDS is grown, it allocates more memory than immediately required (e.g., 1MB of free space for a 1MB string), so subsequent appends may not require a new reallocation and memory copy.</li>
</ul>
<li>Redis dynamically switches internal encodings for a data type based on the data's size and content to save memory. For example </li>
<ul class="ml-4 list-disc">
<li>A Hash with few, small elements might be encoded as a ziplist (or listpack in newer versions), which stores all elements in a single, contiguous block of memory with no pointers, drastically reducing overhead. As the hash grows, Redis automatically converts it to a full hashtable for better performance on large datasets.</li>
<li>A Set containing only integers may be encoded as an intset, a specialized data structure that stores integers in a sorted array without any overhead.</li>
<li>Small Sorted Sets can also be encoded as a ziplist.</li>
</ul>
</ul>
<p class="font-serif text-lg mt-4">That's all from my side for the very first part of deep diving into redis, we got more parts for redis to explore for next few blogs :) Hope I was able to add few value to your today's learning :)</p>
<hr class="my-10">
</description>
<link>https://mrinalxdev.github.io/mrinalxblogs/blogs/redis.html</link>
<guid isPermaLink="false">https://mrinalxdev.github.io/mrinalxblogs/blogs/redis.html</guid>
<pubDate>Wed, 01 Oct 2025 16:00:00 GMT</pubDate>
<author>Mrinal</author>
</item>
<item>
<title>Distributed Systems 101 : From a Beginners POV</title>
<description><hr class="mt-3">
<h1 class="text-4xl mt-[57px] mb-3 font-serif">
Distributed Systems 101 : From a Beginners POV
</h1>
<span class="text-sm text-gray-500">8th August, 2025</span>
<p class="text-lg font-serif mt-6">
Distributed Systems is one best topics which I encounter on daily basis. A
collection of computers or nodes which are independent have to work
together to perform a task, isn't this alone so much interesting to know
how does it all work behind the scene ??
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/banner.png" class="w-[70%] mx-auto my-10" alt="" referrerpolicy="no-referrer">
<h1 class="text-2xl font-serif">The Foundation</h1>
<p class="text-lg font-serif mt-4">
For the very simple start, distributed system is a collection of
independent computers or we also call it nodes, that appear to users as a
single coherent (as one) system. These computers communicate over a
network to coordinate their actions and share resources.
</p>
<p class="text-lg font-serif mt-4">
But the fundamental challenge is making multiple independent computers
work together seamlessly while dealing with network delays, failures and
inconsistency
</p>
<p class="text-lg font-serif mt-4">
Cool isn't it, but what happens when these independent computers can't
agree on something ?? What happens then ??
</p>
<h1 class="text-2xl font-serif my-7">
Why distributed systems can't be perfect ?
</h1>
<p class="text-lg font-serif">
When independent computers in a distributed system can't agree, it creates
a conflict that must be resolved to main system reliability. This
challenge is addressed by the CAP theorem, which states that a distributed
system can only guarantee two out of three properties which is
<span class="font-bold">Consistency</span> this ensure all nodes have the
same data at the same time,
<span class="font-bold">Availability</span> ensures every request receives
a response, and <span class="font-bold">Partition Tolerance</span> ensures
the system continues to operate despite network failures. Now according to
this theorem we need to have 2/3 ratio and sacrifice one :(
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/cap.png" class="w-[60%] my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">
Here comes another one, network partition (P) will happen in any real
distributed system. Internet get cut, routers fail, data centers lose
connectivity. So we must choose between C and A
</p>
<p class="text-lg font-serif mt-4">
Consistency focused systems (CP), like banking databases, ensures all
nodes have the same accurate data, such as correct account balances, even
if it means temporarily halting operations during a failure (that means
sacrificing A of CAP). For example, MongoDB stops accepting updates during
network issues to maintain data accuracy
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/CP.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">
Whereas, Availability focused systems like DNS or Amazon's shopping cart,
keep operating despite failure, even if it risks delivering slightly
outdated information (that means sacrificing C of CAP). For example an old
IP address or an inconsistent cart count
</p>
<p class="text-lg font-serif mt-4">
Everything is cool, but if we have to choose between consistency and
availability, how do we actually make that choice in practice?
</p>
<h1 class="text-2xl font-serif my-6">
The Spectrum of "Good Enough" | Consistency Models
</h1>
<p class="text-lg font-serif">
The answer lies in selecting the right consistency model a set of rules
defining how “consistent” the system’s data needs to be. Different
applications have different needs. <span>Strong Consistency</span> ensures
that every read retrieves the latest write, providing a unified view of
data across all nodes. This is serious for systems like banking databases,
where showing an outdated account balance could cause serious issues.
Traditional databases like PostgreSQL often use this model, but it comes
at a cost: slower response times and reduced availability during network
issues, as the system waits to ensure all nodes agree. <br>
<span class="font-bold">Eventual Consistency</span> prioritizes
availability, allowing temporary differences in data across nodes, with
the promise that updates will sync over time. For example, in Amazon’s
DynamoDB or email systems, a sent message might take a moment to appear
everywhere, but the system stays operational. This model suits
applications where slight delays are acceptable, offering high
availability and the ability to scale easily. <br>
<span class="font-bold">Casual Consistency</span> ensures that events with
a cause-and-effect relationship are seen in the correct order. Like on
social media platforms, everyone sees a reply after its original post, but
unrelated posts might appear in different orders for different users. This
strikes a balance between strict consistency and flexibility, maintaining
logical order for related actions without requiring instant global
agreement. <br>
<span class="font-bold">Session Consistency</span> ensures that within a
single user session, a user sees their own changes immediately. For
example, when we upload a photo to a platform like Facebook, we see it
right away, even if it takes a moment to appear for others. This model
enhances user experience by prioritizing personal consistency while
allowing slight delays for others. <br>
<span></span>
</p>
<p class="text-lg font-serif mt-4">Why "Eventual Consistency" wins ??</p>
<p class="text-lg font-serif mt-4">
Most successful companies, especially those operating at massive scale,
lean toward eventual consistency. Why? Users rarely notice brief delays in
data syncing, and the high availability and scalability it offers outweigh
the need for instant consistency in many cases. Systems like Amazon’s
shopping cart or WhatsApp prioritize staying online and responsive, even
if it means occasional, minor inconsistencies. By carefully choosing a
consistency model that aligns with their priorities, companies ensure
their distributed systems are both reliable and efficient, meeting user
needs without overcomplicating the infrastructure.
</p>
<p class="text-lg font-serif mt-4">
This makes sense, but how do we actually implement these consistency
guarantees ?? What happens under the hood when we're trying to keep data
synchronized across multiple machines?
</p>
<h1 class="font-serif text-2xl my-7">Getting Computers to Agree | Consensus Algorithms</h1>
<p class="text-lg font-serif">Here consensus algorithms work in, they are the mechanisms that allow nodes to agree on shared state, even when some are unreliable. Consensus algorithms ensure everyone ends up on the same page</p>
<p class="text-lg font-serif mt-4">The challenge, often called the Byzantine Generals Problem, tells the core issue: a group of generals (nodes) must agree to attack or retreat together, but some messages might get lost, and some generals could even act maliciously. In distributed systems, nodes face similar obstacles—network delays, crashes, or even intentional sabotage and still need to reach a unified decision.</p>
<p class="text-lg font-serif mt-4">One widely used solution is the <span class="font-bold">Raft algorithm</span>, which simplifies consensus by electing a leader. The process works in three steps: nodes vote to select a leader, the leader handles all client requests and replicates them to follower nodes, and changes are finalized only when a majority of nodes confirm they’ve received them. For example <span class="font-bold">etcd</span>, a key-value store used by Kubernetes, relies on Raft to maintain consistent cluster state across nodes, ensuring reliable coordination even if some nodes fail.</p>
<p class="text-lg font-serif mt-3">Another approach is the <span class="font-bold">Paxos algorithm</span>, favored in academic settings and used by systems like Google’s Chubby lock service. Paxos is robust, handling complex failure scenarios, but it’s harder to implement due to its complexity. <br> <wbr>here malicious nodes are a concern, like in blockchain, the <span class="font-bold">Practical Byzantine Fault Tolerance (PBFT)</span> algorithm steps in. PBFT ensures agreement even when some nodes behave dishonestly, though it’s slower and more resource-intensive.</p>
<p class="text-lg font-serif mt-3">Few Notes on trade offs we are making while using these</p>
<p class="text-lg font-serif mt-3">Raft is fast and straightforward but assumes nodes fail innocently. PBFT handles malicious nodes but sacrifices speed. Proof of Work offers high security at the cost of efficiency.</p>
<p class="text-lg font-serif mt-3">Okay, so we can get computers to agree on things, but what about the actual data ?? How do we store and retrieve information across multiple machines efficiently ??</p>
<h1 class="text-2xl font-serif my-7">Data Partitioning and Sharding</h1>
<p class="text-lg font-serif">I have written an overview of data partitioning in this blog <a class="italic underline underline-offset-4" href="https://mrinalxdev.github.io/mrinalxblogs/blogs/system-design.html">System Design 101</a> you can check this out too. </p>
<p class="text-lg font-serif mt-4">To handle massive datasets in distributed systems, data partitioning or sharding splits information across multiple machines, enabling scalability and faster queries. <span class="font-bold">Range Based Partitioning</span> divides data into segments based on a key’s value range, such as sorting user records by surname. For example, one node might store surnames A–F, another G–M, and a third N–Z. This approach shines for range queries, like finding all users with surnames starting with “C,” as the system knows exactly which node to check. However, it can lead to uneven data distribution if some ranges are more populated like having many “Singh”s in one partition causing bottlenecks.</p>
<p class="text-lg font-serif mt-4"><span class="font-bold">Hash-Based Partitioning </span> uses a hash function to evenly distribute data across nodes. Like, a user ID might be hashed and assigned to one of several partitions, ensuring a balanced spread. If user ID 12345 hashes to partition 1 and 67890 to partition 3, the load stays roughly equal across nodes. This method excels for scalability and uniform data distribution, making it ideal for systems like Apache Cassandra.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/hash-partition.png" class="w-[70%] my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">The downside? Range queries become slower, as the system may need to check all partitions, since hashed values don’t preserve order.</p>
<p class="text-lg font-serif mt-4"><span class="font-bold">Directory Based Partitioning</span> relies on a lookup service to track where each piece of data is stored. Instead of calculating a partition based on the data itself, the system queries a directory to find the right node. Amazon’s DynamoDB uses this approach to route data efficiently using partition keys. This method offers flexibility, as it can adapt to complex data placement needs, but the lookup service must be fast and reliable to avoid becoming a performance bottleneck.</p>
<p class="text-lg font-serif mt-3">All these are cool for storing data, but how do we ensure our data doesn't disappear when machines fail ??</p>
<h1 class="text-2xl font-serif my-7">Replication</h1>
<p class="text-lg font-serif">It plays as a major role, replication is technique that create multiple copies of data across different nodes to ensure fault tolerance. Like keeping copies of vital documents in a safe deposit box and the cloud, replication ensures your data remains accessible and secure even if a machine goes offline. </p>
<p class="text-lg font-serif mt-4">There are types of replications too (I am way too cooked while writing this)</p>
<p class="text-lg font-serif mt-4"><span class="font-bold">Master-Slave (Primary - Replica) Replication</span> <br> In this model, one primary server handles all write operations, while multiple replica servers handle read requests. The primary server sends updates to the replicas, which store copies of the data. For example, MySQL’s master-slave setup uses this approach. A client writes to the primary, and the changes are copied to replicas, from which clients can read. This setup is straightforward, ensures consistent writes through a single source of truth, and scales well for read-heavy workloads, but if the primary server fails, writes are disrupted until a new primary is chosen. Additionally, replication lag can lead to slightly outdated data on replicas</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/master-slave.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-4"><span class="font-bold">Master - Master (Multi Primary) Replication</span> <br>
Here, multiple servers can handle both reads and writes, synchronizing changes between them. Systems like CouchDB or MySQL’s master-master configuration use this model, allowing clients to interact with any primary node. This is useful for geographically distributed systems, where users in different regions can write to nearby servers. This eliminates a single point of failure for writes and improves scalability for both reads and writes but synchronizing writes across multiple primaries can lead to conflicts, requiring complex resolution mechanisms, and managing the system is more challenging.
</p>
<p class="text-lg font-serif mt-5"><span class="font-bold">Peer to Peer Replication</span> <br>
In peer-to-peer replication, all nodes are equal, capable of handling both read and write requests, with data copied to multiple nodes. Systems like Apache Cassandra and Amazon DynamoDB use this approach, often relying on consensus algorithms to maintain consistency. Any node can serve client requests, and data is replicated to a set number of nodes for redundancy.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/master-master.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg">Small Note : MySQL’s master-slave setup is ideal for read-heavy applications, while Cassandra’s peer-to-peer model suits systems needing high availability across regions</p>
<p class="text-lg font-serif mt-4">replication protects our data, but what about when users are scattered across the globe ?? How do we serve them efficiently from the closes location ??</p>
<h1 class="text-2xl font-serif my-7">Content Delivery Network (CDNs)</h1>
<p class="text-lg font-serif">CDNs comes in clutch to deliver content from the closest possible location, slashing latency and performance. Like you can imagine the frustration of waiting for a webpage to load, CDNs solves this by bringing data closer to you.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/cdn.png" class="mx-auto my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">The problem starts with physics: data travels through fiber optic cables at about 200,000 km/second, which sounds fast but isn’t enough for today’s expectations. For instance, a round trip from New York to Sydney (~15,000 km) takes ~75ms just for light to travel, and with routing, processing, and queuing, you’re looking at 200–300ms of delay. Yet, users demand web pages to load in under 100ms. CDNs resolve this by acting like local coffee shops scattered worldwide, serving content quickly instead of relying on one distant central hub.</p>
<p class="text-lg font-serif mt-4">CDNs work by deploying edge servers, or Points of Presence (PoPs), in strategic locations: major cities like New York and Tokyo (Tier 1), regional hubs like Austin or Osaka (Tier 2), and even smaller cities for popular content (Tier 3). When a user requests content, like a video or webpage, the request goes to the nearest edge server. If the content is cached there, it’s served instantly. If not, the edge server fetches it from the origin server, caches it locally, and delivers it to the user, minimizing future delays.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/cdn-working.png" class="w-[70%] my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">CDNs works well with static content, like images, CSS, JavaScript files, videos, or software downloads, which can be cached for hours, days, or weeks since they rarely change. Dynamic content, like personalized web pages or real-time API responses, is trickier. Solutions like Edge-Side Includes (ESI) cache page templates while inserting dynamic parts, or caching different versions for user segments, help balance speed and accuracy.</p>
<p class="text-lg font-serif mt-3">Netflix serves 95% of its traffic through its custom CDN, Open Connect, with appliances in ISP data centers. Popular shows are pre-positioned worldwide based on predictive algorithms, ensuring fast streaming with minimal buffering. YouTube delivers billions of hours of video daily, caching popular videos at edge servers and adjusting quality based on your connection. Steam uses CDNs to distribute massive game downloads, saturating your connection while reducing strain on central servers.</p>
<p class="text-lg font-serif mt-3">There are challenges here too, one is known as <span class="font-bold">Cache Invalidation</span> updating cached content when the origin changes—is notoriously tough. Strategies like Time To Live (TTL) for automatic expiration, manual purging, or URL versioning help. <span class="font-bold">Cache coherence</span> is another different edge servers might hold different versions of content. Eventual consistency or regional cache hierarchies can address this.</p>
<p class="text-lg font-serif mt-6">All this from my side on Distributed System 101 : Part 1, for the part 2 I have some interesting topics to cover and some use cases to share which I learned during my internships. Hope I was able to make you learn something new today .. HAVE A GREAT DAY AHEAD :)</p>
<hr class="my-10">
</description>
<link>https://mrinalxdev.github.io/mrinalxblogs/blogs/distributed-systems.html</link>
<guid isPermaLink="false">https://mrinalxdev.github.io/mrinalxblogs/blogs/distributed-systems.html</guid>
<pubDate>Thu, 07 Aug 2025 16:00:00 GMT</pubDate>
<author>Mrinal</author>
</item>
<item>
<title>Sockets 101 : From a Beginners POV</title>
<description><hr class="mt-3">
<h1 class="text-4xl mt-[57px] mb-3 font-serif">
Sockets 101 : From a Beginners POV
</h1>
<span class="text-sm text-gray-500">26th July, 2025</span>
<p class="text-lg font-serif mt-4">
When your web browser fetches this blog post, when your messaging app
sends a text, or when you stream a video, there's a fundamental mechanism
at work, we call it SOCKETS
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/banner.png" class="w-[75%] mx-auto my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-4">
Sockets are the endpoints of communication channels that allow processes
to exchange data, whether they're on the same machine or across the globe.
At its core, a socket is an abstraction provided by the operating system
that represents one endpoint of a bidirectional communication link. The
socket API, originally developed for Unix systems, has become the standard
interface for network programming across virtually.
</p>
<p class="text-lg font-serif mt-3">
Socket operate at different layers of the network stack. TCP sockets
provide reliable, ordered data delivery with error detection and
correction. UDP sockets offer faster, connection less communication
without delivery guarantees
</p>
<p class="text-lg font-serif mt-4">
The socket abstraction hides the complexity of network protocols, hardware
interface and routing decisions. When you create a socket, the operating
systems allocates kernel data structures, assigns network resources, and
manages the connection lifecycle. This abstraction enables developers to
focus on application logic rather than low-level network details.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/abstraction.png" class="my-10 w-[60%] mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-4">
But how do processes on the same machine communicate without going through
the network stack at all ??
</p>
<h1 class="text-2xl font-serif my-7">The Silent Communication Channel</h1>
<p class="text-lg font-serif">
An anonymous pipe is a unidirectional communication channel that exists
only in memory. Unlike named pipes (FIFOs), anonymous pipes have no
filesystem representation and can only be shared between related
processes, typically a parent and its child processes
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/layers.png" class="mx-auto w-[70%] my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">
The kernel implements anonymous pipes using a circular buffer, typically
64KB on Linux systems. This buffer acts as a temporary storage area
between the writing and reading processes. When the buffer fills up,
writers are blocked until readers consume data, providing natural flow
control.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
Anonymous Pipes working in C
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"stdio.h"&gt;
#include &lt;"unistd.h"&gt;
#include &lt;"stdio.h"&gt;
int main() {
int pipefd[2];
pid_t pid;
// creating a pipe
if (pipe(pipefd) == -1) {
perror("pipe");
return 1;
}
pid = fork();
if (pid == 0) {
// child process - writer
close(pipefd[0]); // Close read end
write(pipefd[1], "Hello from child", 16);
close(pipefd[1]);
} else {
//parent process - reader
char buffer[20];
close(pipefd[1]); // Close write end
read(pipefd[0], buffer, 16);
printf("Received: %s\n", buffer);
close(pipefd[0]);
}
return 0;
}
</code></pre>
</details>
<p class="font-serif text-lg">
The pipe() system call creates two file descriptors: pipefd[0] for reading
and pipefd[1] for writing. The kernel maintains a circular buffer
(typically 64KB on Linux) between these endpoints. When the buffer fills
up, writers block until readers consume data.
</p>
<p class="font-serif text-lg mt-3">
The creation of anonymous pipes involves the operating system allocating
two file descriptors: one for reading and one for writing. These
descriptors can be inherited by child processes through fork(), enabling
parent-child communication. The pipe exists as long as at least one
process holds either descriptor open.
</p>
<p class="font-serif text-lg mt-4">
Unlike network sockets, pipes operate entirely within kernel memory,
making them extremely fast for local communication. There's no network
protocol overhead, no packet serialization, and no routing decisions just
direct memory-to-memory data transfer managed by the kernel.
</p>
<p class="font-serif text-lg mt-2">
But what exactly are these file descriptors that pipes return, and how
does the operating system manage them?
</p>
<h1 class="text-2xl font-serif my-6">File Descriptors</h1>
<p class="font-serif text-lg">
File descriptors are the answer to our previous question about how the OS
manages communication endpoints. A file descriptor (fd) is a non-negative
integer that serves as an abstract handle for accessing files, sockets,
pipes, devices, and other I/O resources in Unix-like systems.
</p>
<p class="font-serif text-lg mt-3">
The operating system maintains a file descriptor table for each process,
mapping fd numbers to kernel data structures that contain the actual
details about the resource. This indirection allows the kernel to manage
resources centrally while providing processes with simple integer handles.
</p>
<!-- <details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
File Descriptors in C
</summary>
<pre class="font-mono text-sm p-4">
<code class="language-c">#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
int main() {
// Creating different types of file descriptors
// 1. Socket file descriptor
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
printf("Socket fd: %d\n", sockfd);
// 2. File descriptor for regular file
int filefd = open("/tmp/test.txt", O_CREAT | O_RDWR, 0644);
printf("File fd: %d\n", filefd);
// 3. Pipe file descriptors
int pipefd[2];
pipe(pipefd);
printf("Pipe read fd: %d, write fd: %d\n", pipefd[0], pipefd[1]);
// All can be used with same I/O operations
char buffer[100];
read(sockfd, buffer, 100); // Read from socket
read(filefd, buffer, 100); // Read from file
read(pipefd[0], buffer, 100); // Read from pipe
close(sockfd);
close(filefd);
close(pipefd[0]);
close(pipefd[1]);
return 0;
}
</code></pre>
</details> -->
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
File Descriptors in C
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/socket.h"&gt;
#include &lt;"netinet/in.h"&gt;
#include &lt;"unistd.h"&gt;
int main() {
// Creating different types of file descriptors
// 1. Socket file descriptor
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
printf("Socket fd: %d\n", sockfd);
// 2. File descriptor for regular file
int filefd = open("/tmp/test.txt", O_CREAT | O_RDWR, 0644);
printf("File fd: %d\n", filefd);
// 3. Pipe file descriptors
int pipefd[2];
pipe(pipefd);
printf("Pipe read fd: %d, write fd: %d\n", pipefd[0], pipefd[1]);
// All can be used with same I/O operations
char buffer[100];
read(sockfd, buffer, 100); // Read from socket
read(filefd, buffer, 100); // Read from file
read(pipefd[0], buffer, 100); // Read from pipe
close(sockfd);
close(filefd);
close(pipefd[0]);
close(pipefd[1]);
return 0;
}
</code>
</pre>
</details>
<p class="text-lg font-serif">
Whether we are dealing with network socket, a regular file, or a pipe, you
use the same system calls : read(), write(), close(), and others. This
abstraction is what makes Unix-like systems so powerful for system
programming.
</p>
<p class="text-lg font-serif">
File descriptors are process-specific resources. When a process forks, the
child inherits copies of the parent's file descriptors, but subsequent
operations on these descriptors in either process don't affect the other.
However, both processes share the same underlying kernel file description,
so operations like changing file position affect both processes.
</p>
<p class="text-lg font-serif">
The kernel enforces limits on file descriptors to prevent resource
exhaustion. Each process has both soft and hard limits on the maximum
number of open file descriptors. These limits can typically be viewed and
modified using system utilities, and they're crucial for server
applications that handle many concurrent connections.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/kfd.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg">
But how do we efficiently monitor multiple file descriptors for activity
without constantly polling them?
</p>
<h1 class="text-2xl font-serif my-7">Managing Multiple Connections</h1>
<p class="text-lg font-serif">
I/O multiplexing solves the challenge of monitoring multiple file
descriptors simultaneously. Instead of creating separate threads for each
connection or constantly polling each descriptor, multiplexing allows a
single thread to wait for activity on multiple file descriptors at once.
</p>
<p class="text-lg font-serif mt-3">
The fundamental problem that I/O multiplexing addresses is the blocking
nature of I/O operations. When a process calls read() on a socket with no
available data, the process blocks until data arrives. For a server
handling multiple clients, this means either dedicating one thread per
connection or missing data from other connections.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/multi.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">
I/O multiplexing enables a single process to efficiently handle multiple
input/output sources, such as sockets, without blocking on each one
individually. The application process communicates with an I/O multiplexer
(e.g., select, poll, or epoll), requesting it to monitor a set of file
descriptors (FDs) in this case, three socket FDs. The multiplexer
continuously checks the status of these FDs and blocks the process until
one or more of them become "ready" (e.g., data is available to read). When
an event occurs on a monitored FD (like FD 1 or FD 3 becoming readable),
the multiplexer returns control to the process with information about
which FDs are ready.
</p>
<p class="text-lg font-serif mt-3">
The process can then perform non-blocking I/O only on those specific
descriptors. This mechanism allows efficient use of system resources by
avoiding the need to spawn multiple threads or processes for each I/O
source.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
epoll() in C
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/epoll.h"&gt;
int epoll_fd = epoll_create1(0);
struct epoll_event event, events[MAX_EVENTS];
// Add socket to epoll
event.events = EPOLLIN;
event.data.fd = socket_fd;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, socket_fd, &amp;event);
// Wait for events
int num_events = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
</code>
</pre>
</details>
<p class="text-lg font-serif mt-3">
I/O multiplexing enables servers to handle thousands of concurrent
connections with a single thread, but what about connections that are
meant to be temporary and don't need to persist?
</p>
<h1 class="font-serif text-2xl my-6">The Temporary Connection Endpoints</h1>
<p class="font-serif text-lg mt-2">
Ephemeral ports provide the answer to temporary connections. When a client
application creates an outbound connection, it doesn't typically specify a
source port. Instead, the operating system automatically assigns an
ephemeral (temporary) port from a predefined range.
</p>
<p class="font-serif text-lg mt-2">
The ephemeral port range varies by operating system. Linux typically uses
ports 32768-60999, while Windows uses 1024-65535. These ranges are
configurable and represent a balance between providing enough ports for
concurrent connections while reserving lower-numbered ports for well-known
services.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
How ephermal ports work in practice
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/socket.h"&gt;
#include &lt;"netinet/in.h"&gt;
#include &lt;"arpa/inet.h"&gt;
int main() {
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in server_addr, local_addr;
socklen_t addr_len = sizeof(local_addr);
// Connect to server (OS assigns ephemeral port automatically)
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(80);
inet_pton(AF_INET, "93.184.216.34", &amp;server_addr.sin_addr); // example.com
connect(sockfd, (struct sockaddr*)&amp;server_addr, sizeof(server_addr));
// Check what ephemeral port was assigned
getsockname(sockfd, (struct sockaddr*)&amp;local_addr, &amp;addr_len);
printf("Local port assigned: %d\n", ntohs(local_addr.sin_port));
close(sockfd);
return 0;
}
</code>
</pre>
</details>
<p class="text-lg font-serif mt-3">
Ephemeral port allocation strategies differ across operating systems. Some
use sequential allocation, starting from the lowest available port in the
range. Others use random or hash-based algorithms to distribute ports more
evenly across the range. The choice affects performance, security, and the
ability to handle high connection rates.
</p>
<p class="text-lg font-serif mt-3">
The lifecycle of an ephemeral port begins when a client initiates an
outbound connection. The operating system selects an available port, binds
it to the socket, and uses it as the source port for the connection. When
the connection closes, the port enters a TIME_WAIT state before becoming
available for reuse.
</p>
<div class="my-10">
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/ephermal.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-sm text-gray-500 text-center font-serif">
TCP (Transmission Control Protocol) state machine, which outlines the
various states a TCP connection transitions through during its
lifecycle.
</p>
</div>
<p class="font-serif text-lg">
TIME_WAIT is a crucial TCP state that prevents delayed packets from a
closed connection from interfering with new connections using the same
port pair. The typical TIME_WAIT duration is twice the Maximum Segment
Lifetime (MSL), often 60-120 seconds. This can become a limiting factor
for applications making many short-lived connections.
</p>
<p class="font-serif text-lg">
Port exhaustion occurs when all ephemeral ports are in use or in TIME_WAIT
state. This is a common problem for high-traffic proxy servers or
applications making many outbound connections. Solutions include using
multiple IP addresses, tuning TIME_WAIT parameters, or implementing
connection pooling.
</p>
<h1 class="font-serif text-2xl my-6">Raw Sockets and custom protocols</h1>
<p class="font-serif text-lg">
What about scenarios where we need to implement custom protocols or handle
raw network data?
</p>
<p class="text-lg font-serif mt-2">
Raw sockets provide direct access to network protocols below the transport
layer, allowing applications to craft custom packets or implement
protocols not directly supported by the operating system.
</p>
<p class="text-lg font-serif mt-2">
Operating systems typically provide TCP and UDP socket abstractions that
handle most application needs. However, some applications require
lower-level access to implement custom protocols, perform network
analysis, or bypass standard protocol limitations.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
Implementing raw sockets
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/socket.h"&gt;
#include &lt;"netinet/ip.h"&gt;
#include &lt;"netinet/tcp.h"&gt;
#include &lt;"arpa/inet.h"&gt;
// Creating a raw socket (requires root privileges)
int create_raw_socket() {
int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
if (sockfd &lt; 0) {
perror("raw socket creation failed");
return -1;
}
// Tell kernel not to add IP header (we'll craft it ourselves)
int one = 1;
if (setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, &amp;one, sizeof(one)) &lt; 0) {
perror("setsockopt IP_HDRINCL failed");
return -1;
}
return sockfd;
}
// Craft a custom TCP packet
void craft_tcp_packet(char *packet, const char *src_ip, const char *dst_ip,
uint16_t src_port, uint16_t dst_port) {
struct iphdr *ip_header = (struct iphdr *)packet;
struct tcphdr *tcp_header = (struct tcphdr *)(packet + sizeof(struct iphdr));
// Fill IP header
ip_header-&gt;version = 4;
ip_header-&gt;ihl = 5;
ip_header-&gt;tos = 0;
ip_header-&gt;tot_len = htons(sizeof(struct iphdr) + sizeof(struct tcphdr));
ip_header-&gt;id = htons(12345);
ip_header-&gt;frag_off = 0;
ip_header-&gt;ttl = 64;
ip_header-&gt;protocol = IPPROTO_TCP;
ip_header-&gt;check = 0; // Kernel will calculate
inet_pton(AF_INET, src_ip, &amp;ip_header-&gt;saddr);
inet_pton(AF_INET, dst_ip, &amp;ip_header-&gt;daddr);
// Fill TCP header
tcp_header-&gt;source = htons(src_port);
tcp_header-&gt;dest = htons(dst_port);
tcp_header-&gt;seq = htonl(1000);
tcp_header-&gt;ack_seq = 0;
tcp_header-&gt;doff = 5;
tcp_header-&gt;syn = 1; // SYN flag
tcp_header-&gt;window = htons(65535);
tcp_header-&gt;check = 0; // Calculate separately
tcp_header-&gt;urg_ptr = 0;
}
</code>
</pre>
</details>
<p class="text-lg font-serif mt-">
Raw sockets operate at the IP level or even lower, depending on the socket
type and options. Applications using raw sockets must manually construct
protocol headers and handle details normally managed by the operating
system, such as checksums, fragmentation, and addressing.
</p>
<h1 class="text-2xl font-serif my-6">
Notes on Performance and Optimization
</h1>
<p class="text-lg font-serif">
Buffer management significantly impacts socket performance. The
bandwidth-delay product determines optimal buffer sizes - the product of
network bandwidth and round-trip time indicates how much data should be
"in flight" for maximum throughput. Undersized buffers limit throughput,
while oversized buffers waste memory.
</p>
<p class="text-lg font-serif mt-3">
Connection reuse and pooling strategies reduce the overhead of connection
establishment and teardown. HTTP/1.1 introduced persistent connections to
avoid repeated TCP handshakes. HTTP/2 multiplexes multiple streams over
single connections. Connection pools maintain ready-to-use connections to
frequently accessed servers.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
Connection reusing and pooling
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">typedef struct {
int *sockets;
int count;
int capacity;
pthread_mutex_t mutex;
} connection_pool_t;
int get_connection(connection_pool_t *pool, const char *host, int port) {
pthread_mutex_lock(&amp;pool-&gt;mutex);
if (pool-&gt;count &gt; 0) {
// Reuse existing connection
int sockfd = pool-&gt;sockets[--pool-&gt;count];
pthread_mutex_unlock(&amp;pool-&gt;mutex);
return sockfd;
}
pthread_mutex_unlock(&amp;pool-&gt;mutex);
// Create new connection
return create_connection(host, port);
}
void return_connection(connection_pool_t *pool, int sockfd) {
pthread_mutex_lock(&amp;pool-&gt;mutex);
if (pool-&gt;count &lt; pool-&gt;capacity) {
pool-&gt;sockets[pool-&gt;count++] = sockfd;
} else {
close(sockfd); // Pool full, close connection
}
pthread_mutex_unlock(&amp;pool-&gt;mutex);
}
</code>
</pre>
</details>
<p class="text-lg font-serif">
Memory mapping can improve performance for applications that repeatedly
access the same data. By mapping files into memory, applications can avoid
system call overhead and benefit from the operating system's virtual
memory management.
|
TonyRL
reviewed
Jan 16, 2026
TonyRL
reviewed
Jan 16, 2026
jack-110
force-pushed
the
route/mrinalxdev-blog
branch
from
ce835a1 to
f64c05d
Compare
Contributor
|
Successfully generated as following: http://localhost:1200/mrinalxdev/blog - Success ✔️<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
<channel>
<title>Mrinal's Blog</title>
<link>https://mrinalxdev.github.io/mrinalxblogs/blogs/blog.html</link>
<atom:link href="http://localhost:1200/mrinalxdev/blog" rel="self" type="application/rss+xml"></atom:link>
<description>Technical blog by Mrinal covering Redis, Distributed Systems, Algorithms, and more. - Powered by RSSHub</description>
<generator>RSSHub</generator>
<webMaster>contact@rsshub.app (RSSHub)</webMaster>
<language>en</language>
<lastBuildDate>Sat, 17 Jan 2026 13:37:22 GMT</lastBuildDate>
<ttl>5</ttl>
<item>
<title>Redis 101 : From a Beginners POV</title>
<description><hr class="mt-3">
<h1 class="text-4xl mt-[57px] mb-3 font-serif">
Redis 101 : From a Beginners POV
</h1>
<span class="text-sm text-gray-500">2nd October, 2025</span>
<p class="text-lg font-serif mt-4">
Whenever I have talked about redis in my projects people woud think it as a cache to use . But redis is more than that we can use redis as rate limiter, message broker and as a database ... But what is even redis, why is it even so fast and how are we even using it . Raising all this question made me curious about this topic and so I want you to be ...
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/banner.png" class="w-[750px] mx-auto my-10" alt="" referrerpolicy="no-referrer">
<h1 class="text-2xl font-serif">Foundation</h1>
<p class="font-serif mt-4 text-lg">Lets first start with <span class="font-bold">What is Cache</span> so its simple caching is like keeping frequently used items on your desk instead of fetching them from a storage room. Caching stores frequently accessed data in a temporary, high-speed storage layer, reducing latency and improving performance by minimizing redundant computations or database queries. Now Redis is our <span class="font-bold">high speed storage layer</span> stands for remote dictionary server, its a single threaded, in memory data structure storage model .. Which means unlike databases like PostgreSQL, MySQL which stores data on slower mechanical or solid state drives, redis keeps all its data in RAM. This means every read and write operation happens at memory speed wihtout the worrying about disk input / output </p>
<h1 class="text-2xl font-serif my-7">Why Redis is this fast ??</h1>
<p class="font-serif text-lg mt-3">There are three main pillers behind this speed, first being the <span class="font-bold">In Memory Data Storage</span>, this is the most significant factor as accessing data from RAM is orders of magnitude faster than from even the fastest SSDs or NVMe drives. Main memory access latency is typically in the nanosecond range, while disk access is in the microsecond to millisecond range. By keeping the entire dataset in RAM, redis eliminates biggest bottleneck in database systems which is disk I/O</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/ram.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg mt-3">Second reason being <span class="font-bold">Single threaded command execution</span>, redis processes all commands on a single thread. This design avoids the overhead of multithreading. There are no locks to acquire, no context switching between threads and no race conditions to manage. The CPU can focus purely on executing commands sequentially without interruption, which is incredibly efficient for the workload Redis is designed for (many small, fast operations).</p>
<p class="font-serif text-lg mt-3">Third reason being <span class="font-bold">highly optimized C code and data structures</span>, redis is written in ANSI C, a language known for its performance. Beyond the language, it uses custom, highly-tuned data structures. For example, its Simple Dynamic String (SDS) and the various encodings for Hashes and Sets (like ziplists) are designed to minimize memory usage and CPU cycles for common operations, ensuring that not only is the data in RAM, but it's stored in the most efficient way possible.</p>
<p class="text-lg font-serif mt-4">You might get a question that redis must handle thousand of concurrent client connections and execute commands with microsecond latency, what architectural mode allows it to manage this so effieciently??</p>
<h1 class="my-6 text-2xl font-serif">The single threaded nature</h1>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/concurrency/multi-threaded.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">The core of Redis's command processing is single threaded. This means it uses a single CPU core to process all incoming commands, parse them and execute them. This choice is intentional,as it eliminates the complexity and performance overhead of multithreading, such as lock contention, race condition and context switching</p>
<p class="text-lg font-serif mt-3">To handle concurrency, redis employes an event driven architecture using an <span class="font-bold">I/O multiplexing</span> mechanism. The main thread runs an event loop that uses system calls epoll, kqueue or IOCP to effieciently observe multiple network sockets</p>
<p class="text-lg font-serif mt-3">Lets take up a scene in which you are the only one who knows how to cook and chop veggies, but you can only chop one ingredient at a time(the single redis thread). But you have multiple assistants (your friends ofc) (the operating system's I/0 multiplexing features, like kqueue and IOCP). You told your friends to watch all these pots on the stove. The moment one is ready, they should inform you. All this to not waste your time standing and string at the pots. Instead you chop veggies, when one of your assistant shouts, "pot#3 is boiling !!" then you immediately stop what ever was being done, deal with that pot and then go back to chopping. So in this scenario <span class="font-bold">you</span> are the redis main event loop, <span class="font-bold">pots</span> are client connections and <span class="font-bold">your friends</span> are the operating system's kernel, which efficiently notifies Redis when a client has sent a request or is ready to receive a response.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/io.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">So this is what the actual process looks like : </p>
<ul class="font-serif text-lg list-disc ml-6 my-4">
<li>The event loop registers all client sockets with the multiplexing API.</li>
<li>The API notifies the Redis event loop only when a socket is ready for an I/O operation (e.g., a client has sent data, or a TCP buffer is ready to receive a response).</li>
<li>The single thread then processes the ready event: it reads the command from the socket, parses it, executes it, and writes the response back to the socket.</li>
</ul>
<p class="text-lg font-serif mt-3">This non-blocking I/O model ensures the single thread is never idle waiting for network or disk operations. It is always busy processing events, which is how it achieves high throughput and concurrency with a single thread.</p>
<p class="text-lg font-serif mt-3">As a engineer you should get this question, that Redis's primary storage is volatile RAM. What mechanisms does it provide to ensure data persistence and durability, allowing it to recover from server restarts or crashes? </p>
<h1 class="my-6 text-2xl font-serif">Lets talk about Persistance</h1>
<p class="font-serif text-lg mt-3">Redis provides two distinct, complementary persistence mechanisms to save the in-memory dataset to non-volatile storage.</p>
<ul class="font-serif text-lg list-disc ml-6 my-4">
<li>RDB (Redis Database): This persistence method creates point-in-time snapshots of the dataset. It works by forking a child process, as described previously. The child process writes the entire dataset to a single, compact, binary .rdb file on disk. This is efficient in terms of CPU and I/O. The main advantage is that the resulting file is perfect for backups and allows for fast data restoration on restart. The primary disadvantage is the potential for data loss: if the server crashes between two configured snapshots, all writes since the last snapshot are lost.</li>
<li>AOF (Append Only File): This method logs every write operation command that modifies the dataset. These commands are appended to an appendonly.aof file. Upon restart, Redis re-executes these commands in sequence to reconstruct the original dataset. Durability is controlled by the appendfsync configuration:
<ul class="ml-4 list-decimal">
<li>always: Syncs after every write. Slowest but safest.</li>
<li>everysec: Syncs once per second. The recommended default, providing a good balance of speed and safety (max 1 second of data loss).</li>
<li>no: Lets the OS decide when to flush. Fastest but least safe.</li>
</ul>
</li>
</ul>
<p class="font-serif text-lg mt-3">To prevent the AOF file from growing indefinitely, Redis can automatically rewrite it in the background. It forks a child process that writes the minimal set of commands needed to recreate the current dataset into a new, temporary AOF file, which is then atomically swapped with the old one.</p>
<p class="font-serif text-lg mt-3">For maximum durability, it is common practice to use both AOF for near-real-time persistence and RDB for periodic backups.</p>
<p class="font-serif text-lg mt-3">Lets take a some good use cases of redis in production grade application</p>
<p class="font-serif text-lg mt-3">First which is commonly known and used by every developers and engineers out there, <span class="font-bold">Redis as cache layer</span>.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets//redis/basic-sys.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg mt-3">Lets say you have a web application where users frequently view their profiles fetching this data from a disk based database like MySQL everytime can be slow instead we can use redis to cache the user profile data so when a user requests their profile the application first checks redis, if the desired data is in redis it's a <span class="font-bold">cache hit</span> it is returned immediately, if the data is not in redis it's a <span class="font-bold">cache miss</span> the cache miss the application fetches it from the primary database stores it in redis and then returns it to the user. The data in redis can have <span class="font-bold">TTL</span> or <span class="font-bold">Time To Live</span> so it can automatically expire after a certain time for example say 15 to 20 minutes to ensure fresh is there all the time.</p>
<p class="font-serif text-lg mt-3">Second scenario is using <span class="font-bold">Redis as Database</span> specially for use cases where speed and low latency are very much important, just like building a gaming application.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/redis/rdb.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">Here we need to maintain a realtime leaderboard where player scores are constantly updated and we need to display the top 10 players instantly. So here we can use redis as sorted set data structure to store player scores, each player score is added to the sorted set with their ID as the key and the score as the value this automatically sorts the scores so we can quickly retrieve the top 10 players using a single command like <span class="font-bold">ZREVRANGE leaderboard 0 9</span>. Redis can then process this data to disk using RDB or AOF to ensure durability. </p>
<p class="text-lg font-serif mt-4">What internal data structures and optimizations allow it to store complex data types with minimal overhead?</p>
<h1 class="text-2xl font-serif my-7">Memory Management</h1>
<p class="font-serif text-lg">Redis's memory efficiency stems from its use of custom, highly-optimized data structures and dynamic encoding strategies.</p>
<ul class="text-lg font-serif mt-4 ml-4 list-disc">
<li> Redis does not use standard C-style null-terminated strings. Instead, it uses its own SDS structure. An SDS <span class="font-bold">(Simple Dynamic String)</span> is a struct that contains metadata (like the length of the string and the total allocated memory) followed by a byte array holding the actual data. This design provides several advantages which are</li>
<ul>
<li>O(1) Length Lookup: The length is stored directly in the struct, avoiding the need to scan the entire string.</li>
<li>When an SDS is grown, it allocates more memory than immediately required (e.g., 1MB of free space for a 1MB string), so subsequent appends may not require a new reallocation and memory copy.</li>
</ul>
<li>Redis dynamically switches internal encodings for a data type based on the data's size and content to save memory. For example </li>
<ul class="ml-4 list-disc">
<li>A Hash with few, small elements might be encoded as a ziplist (or listpack in newer versions), which stores all elements in a single, contiguous block of memory with no pointers, drastically reducing overhead. As the hash grows, Redis automatically converts it to a full hashtable for better performance on large datasets.</li>
<li>A Set containing only integers may be encoded as an intset, a specialized data structure that stores integers in a sorted array without any overhead.</li>
<li>Small Sorted Sets can also be encoded as a ziplist.</li>
</ul>
</ul>
<p class="font-serif text-lg mt-4">That's all from my side for the very first part of deep diving into redis, we got more parts for redis to explore for next few blogs :) Hope I was able to add few value to your today's learning :)</p>
<hr class="my-10">
</description>
<link>https://mrinalxdev.github.io/mrinalxblogs/blogs/redis.html</link>
<guid isPermaLink="false">https://mrinalxdev.github.io/mrinalxblogs/blogs/redis.html</guid>
<pubDate>Wed, 01 Oct 2025 16:00:00 GMT</pubDate>
<author>Mrinal</author>
</item>
<item>
<title>Distributed Systems 101 : From a Beginners POV</title>
<description><hr class="mt-3">
<h1 class="text-4xl mt-[57px] mb-3 font-serif">
Distributed Systems 101 : From a Beginners POV
</h1>
<span class="text-sm text-gray-500">8th August, 2025</span>
<p class="text-lg font-serif mt-6">
Distributed Systems is one best topics which I encounter on daily basis. A
collection of computers or nodes which are independent have to work
together to perform a task, isn't this alone so much interesting to know
how does it all work behind the scene ??
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/banner.png" class="w-[70%] mx-auto my-10" alt="" referrerpolicy="no-referrer">
<h1 class="text-2xl font-serif">The Foundation</h1>
<p class="text-lg font-serif mt-4">
For the very simple start, distributed system is a collection of
independent computers or we also call it nodes, that appear to users as a
single coherent (as one) system. These computers communicate over a
network to coordinate their actions and share resources.
</p>
<p class="text-lg font-serif mt-4">
But the fundamental challenge is making multiple independent computers
work together seamlessly while dealing with network delays, failures and
inconsistency
</p>
<p class="text-lg font-serif mt-4">
Cool isn't it, but what happens when these independent computers can't
agree on something ?? What happens then ??
</p>
<h1 class="text-2xl font-serif my-7">
Why distributed systems can't be perfect ?
</h1>
<p class="text-lg font-serif">
When independent computers in a distributed system can't agree, it creates
a conflict that must be resolved to main system reliability. This
challenge is addressed by the CAP theorem, which states that a distributed
system can only guarantee two out of three properties which is
<span class="font-bold">Consistency</span> this ensure all nodes have the
same data at the same time,
<span class="font-bold">Availability</span> ensures every request receives
a response, and <span class="font-bold">Partition Tolerance</span> ensures
the system continues to operate despite network failures. Now according to
this theorem we need to have 2/3 ratio and sacrifice one :(
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/cap.png" class="w-[60%] my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">
Here comes another one, network partition (P) will happen in any real
distributed system. Internet get cut, routers fail, data centers lose
connectivity. So we must choose between C and A
</p>
<p class="text-lg font-serif mt-4">
Consistency focused systems (CP), like banking databases, ensures all
nodes have the same accurate data, such as correct account balances, even
if it means temporarily halting operations during a failure (that means
sacrificing A of CAP). For example, MongoDB stops accepting updates during
network issues to maintain data accuracy
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/CP.png" class="my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">
Whereas, Availability focused systems like DNS or Amazon's shopping cart,
keep operating despite failure, even if it risks delivering slightly
outdated information (that means sacrificing C of CAP). For example an old
IP address or an inconsistent cart count
</p>
<p class="text-lg font-serif mt-4">
Everything is cool, but if we have to choose between consistency and
availability, how do we actually make that choice in practice?
</p>
<h1 class="text-2xl font-serif my-6">
The Spectrum of "Good Enough" | Consistency Models
</h1>
<p class="text-lg font-serif">
The answer lies in selecting the right consistency model a set of rules
defining how “consistent” the system’s data needs to be. Different
applications have different needs. <span>Strong Consistency</span> ensures
that every read retrieves the latest write, providing a unified view of
data across all nodes. This is serious for systems like banking databases,
where showing an outdated account balance could cause serious issues.
Traditional databases like PostgreSQL often use this model, but it comes
at a cost: slower response times and reduced availability during network
issues, as the system waits to ensure all nodes agree. <br>
<span class="font-bold">Eventual Consistency</span> prioritizes
availability, allowing temporary differences in data across nodes, with
the promise that updates will sync over time. For example, in Amazon’s
DynamoDB or email systems, a sent message might take a moment to appear
everywhere, but the system stays operational. This model suits
applications where slight delays are acceptable, offering high
availability and the ability to scale easily. <br>
<span class="font-bold">Casual Consistency</span> ensures that events with
a cause-and-effect relationship are seen in the correct order. Like on
social media platforms, everyone sees a reply after its original post, but
unrelated posts might appear in different orders for different users. This
strikes a balance between strict consistency and flexibility, maintaining
logical order for related actions without requiring instant global
agreement. <br>
<span class="font-bold">Session Consistency</span> ensures that within a
single user session, a user sees their own changes immediately. For
example, when we upload a photo to a platform like Facebook, we see it
right away, even if it takes a moment to appear for others. This model
enhances user experience by prioritizing personal consistency while
allowing slight delays for others. <br>
<span></span>
</p>
<p class="text-lg font-serif mt-4">Why "Eventual Consistency" wins ??</p>
<p class="text-lg font-serif mt-4">
Most successful companies, especially those operating at massive scale,
lean toward eventual consistency. Why? Users rarely notice brief delays in
data syncing, and the high availability and scalability it offers outweigh
the need for instant consistency in many cases. Systems like Amazon’s
shopping cart or WhatsApp prioritize staying online and responsive, even
if it means occasional, minor inconsistencies. By carefully choosing a
consistency model that aligns with their priorities, companies ensure
their distributed systems are both reliable and efficient, meeting user
needs without overcomplicating the infrastructure.
</p>
<p class="text-lg font-serif mt-4">
This makes sense, but how do we actually implement these consistency
guarantees ?? What happens under the hood when we're trying to keep data
synchronized across multiple machines?
</p>
<h1 class="font-serif text-2xl my-7">Getting Computers to Agree | Consensus Algorithms</h1>
<p class="text-lg font-serif">Here consensus algorithms work in, they are the mechanisms that allow nodes to agree on shared state, even when some are unreliable. Consensus algorithms ensure everyone ends up on the same page</p>
<p class="text-lg font-serif mt-4">The challenge, often called the Byzantine Generals Problem, tells the core issue: a group of generals (nodes) must agree to attack or retreat together, but some messages might get lost, and some generals could even act maliciously. In distributed systems, nodes face similar obstacles—network delays, crashes, or even intentional sabotage and still need to reach a unified decision.</p>
<p class="text-lg font-serif mt-4">One widely used solution is the <span class="font-bold">Raft algorithm</span>, which simplifies consensus by electing a leader. The process works in three steps: nodes vote to select a leader, the leader handles all client requests and replicates them to follower nodes, and changes are finalized only when a majority of nodes confirm they’ve received them. For example <span class="font-bold">etcd</span>, a key-value store used by Kubernetes, relies on Raft to maintain consistent cluster state across nodes, ensuring reliable coordination even if some nodes fail.</p>
<p class="text-lg font-serif mt-3">Another approach is the <span class="font-bold">Paxos algorithm</span>, favored in academic settings and used by systems like Google’s Chubby lock service. Paxos is robust, handling complex failure scenarios, but it’s harder to implement due to its complexity. <br> <wbr>here malicious nodes are a concern, like in blockchain, the <span class="font-bold">Practical Byzantine Fault Tolerance (PBFT)</span> algorithm steps in. PBFT ensures agreement even when some nodes behave dishonestly, though it’s slower and more resource-intensive.</p>
<p class="text-lg font-serif mt-3">Few Notes on trade offs we are making while using these</p>
<p class="text-lg font-serif mt-3">Raft is fast and straightforward but assumes nodes fail innocently. PBFT handles malicious nodes but sacrifices speed. Proof of Work offers high security at the cost of efficiency.</p>
<p class="text-lg font-serif mt-3">Okay, so we can get computers to agree on things, but what about the actual data ?? How do we store and retrieve information across multiple machines efficiently ??</p>
<h1 class="text-2xl font-serif my-7">Data Partitioning and Sharding</h1>
<p class="text-lg font-serif">I have written an overview of data partitioning in this blog <a class="italic underline underline-offset-4" href="https://mrinalxdev.github.io/mrinalxblogs/blogs/system-design.html">System Design 101</a> you can check this out too. </p>
<p class="text-lg font-serif mt-4">To handle massive datasets in distributed systems, data partitioning or sharding splits information across multiple machines, enabling scalability and faster queries. <span class="font-bold">Range Based Partitioning</span> divides data into segments based on a key’s value range, such as sorting user records by surname. For example, one node might store surnames A–F, another G–M, and a third N–Z. This approach shines for range queries, like finding all users with surnames starting with “C,” as the system knows exactly which node to check. However, it can lead to uneven data distribution if some ranges are more populated like having many “Singh”s in one partition causing bottlenecks.</p>
<p class="text-lg font-serif mt-4"><span class="font-bold">Hash-Based Partitioning </span> uses a hash function to evenly distribute data across nodes. Like, a user ID might be hashed and assigned to one of several partitions, ensuring a balanced spread. If user ID 12345 hashes to partition 1 and 67890 to partition 3, the load stays roughly equal across nodes. This method excels for scalability and uniform data distribution, making it ideal for systems like Apache Cassandra.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/hash-partition.png" class="w-[70%] my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">The downside? Range queries become slower, as the system may need to check all partitions, since hashed values don’t preserve order.</p>
<p class="text-lg font-serif mt-4"><span class="font-bold">Directory Based Partitioning</span> relies on a lookup service to track where each piece of data is stored. Instead of calculating a partition based on the data itself, the system queries a directory to find the right node. Amazon’s DynamoDB uses this approach to route data efficiently using partition keys. This method offers flexibility, as it can adapt to complex data placement needs, but the lookup service must be fast and reliable to avoid becoming a performance bottleneck.</p>
<p class="text-lg font-serif mt-3">All these are cool for storing data, but how do we ensure our data doesn't disappear when machines fail ??</p>
<h1 class="text-2xl font-serif my-7">Replication</h1>
<p class="text-lg font-serif">It plays as a major role, replication is technique that create multiple copies of data across different nodes to ensure fault tolerance. Like keeping copies of vital documents in a safe deposit box and the cloud, replication ensures your data remains accessible and secure even if a machine goes offline. </p>
<p class="text-lg font-serif mt-4">There are types of replications too (I am way too cooked while writing this)</p>
<p class="text-lg font-serif mt-4"><span class="font-bold">Master-Slave (Primary - Replica) Replication</span> <br> In this model, one primary server handles all write operations, while multiple replica servers handle read requests. The primary server sends updates to the replicas, which store copies of the data. For example, MySQL’s master-slave setup uses this approach. A client writes to the primary, and the changes are copied to replicas, from which clients can read. This setup is straightforward, ensures consistent writes through a single source of truth, and scales well for read-heavy workloads, but if the primary server fails, writes are disrupted until a new primary is chosen. Additionally, replication lag can lead to slightly outdated data on replicas</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/master-slave.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-4"><span class="font-bold">Master - Master (Multi Primary) Replication</span> <br>
Here, multiple servers can handle both reads and writes, synchronizing changes between them. Systems like CouchDB or MySQL’s master-master configuration use this model, allowing clients to interact with any primary node. This is useful for geographically distributed systems, where users in different regions can write to nearby servers. This eliminates a single point of failure for writes and improves scalability for both reads and writes but synchronizing writes across multiple primaries can lead to conflicts, requiring complex resolution mechanisms, and managing the system is more challenging.
</p>
<p class="text-lg font-serif mt-5"><span class="font-bold">Peer to Peer Replication</span> <br>
In peer-to-peer replication, all nodes are equal, capable of handling both read and write requests, with data copied to multiple nodes. Systems like Apache Cassandra and Amazon DynamoDB use this approach, often relying on consensus algorithms to maintain consistency. Any node can serve client requests, and data is replicated to a set number of nodes for redundancy.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/master-master.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg">Small Note : MySQL’s master-slave setup is ideal for read-heavy applications, while Cassandra’s peer-to-peer model suits systems needing high availability across regions</p>
<p class="text-lg font-serif mt-4">replication protects our data, but what about when users are scattered across the globe ?? How do we serve them efficiently from the closes location ??</p>
<h1 class="text-2xl font-serif my-7">Content Delivery Network (CDNs)</h1>
<p class="text-lg font-serif">CDNs comes in clutch to deliver content from the closest possible location, slashing latency and performance. Like you can imagine the frustration of waiting for a webpage to load, CDNs solves this by bringing data closer to you.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/cdn.png" class="mx-auto my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">The problem starts with physics: data travels through fiber optic cables at about 200,000 km/second, which sounds fast but isn’t enough for today’s expectations. For instance, a round trip from New York to Sydney (~15,000 km) takes ~75ms just for light to travel, and with routing, processing, and queuing, you’re looking at 200–300ms of delay. Yet, users demand web pages to load in under 100ms. CDNs resolve this by acting like local coffee shops scattered worldwide, serving content quickly instead of relying on one distant central hub.</p>
<p class="text-lg font-serif mt-4">CDNs work by deploying edge servers, or Points of Presence (PoPs), in strategic locations: major cities like New York and Tokyo (Tier 1), regional hubs like Austin or Osaka (Tier 2), and even smaller cities for popular content (Tier 3). When a user requests content, like a video or webpage, the request goes to the nearest edge server. If the content is cached there, it’s served instantly. If not, the edge server fetches it from the origin server, caches it locally, and delivers it to the user, minimizing future delays.</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/distributed-systems/cdn-working.png" class="w-[70%] my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">CDNs works well with static content, like images, CSS, JavaScript files, videos, or software downloads, which can be cached for hours, days, or weeks since they rarely change. Dynamic content, like personalized web pages or real-time API responses, is trickier. Solutions like Edge-Side Includes (ESI) cache page templates while inserting dynamic parts, or caching different versions for user segments, help balance speed and accuracy.</p>
<p class="text-lg font-serif mt-3">Netflix serves 95% of its traffic through its custom CDN, Open Connect, with appliances in ISP data centers. Popular shows are pre-positioned worldwide based on predictive algorithms, ensuring fast streaming with minimal buffering. YouTube delivers billions of hours of video daily, caching popular videos at edge servers and adjusting quality based on your connection. Steam uses CDNs to distribute massive game downloads, saturating your connection while reducing strain on central servers.</p>
<p class="text-lg font-serif mt-3">There are challenges here too, one is known as <span class="font-bold">Cache Invalidation</span> updating cached content when the origin changes—is notoriously tough. Strategies like Time To Live (TTL) for automatic expiration, manual purging, or URL versioning help. <span class="font-bold">Cache coherence</span> is another different edge servers might hold different versions of content. Eventual consistency or regional cache hierarchies can address this.</p>
<p class="text-lg font-serif mt-6">All this from my side on Distributed System 101 : Part 1, for the part 2 I have some interesting topics to cover and some use cases to share which I learned during my internships. Hope I was able to make you learn something new today .. HAVE A GREAT DAY AHEAD :)</p>
<hr class="my-10">
</description>
<link>https://mrinalxdev.github.io/mrinalxblogs/blogs/distributed-systems.html</link>
<guid isPermaLink="false">https://mrinalxdev.github.io/mrinalxblogs/blogs/distributed-systems.html</guid>
<pubDate>Thu, 07 Aug 2025 16:00:00 GMT</pubDate>
<author>Mrinal</author>
</item>
<item>
<title>Sockets 101 : From a Beginners POV</title>
<description><hr class="mt-3">
<h1 class="text-4xl mt-[57px] mb-3 font-serif">
Sockets 101 : From a Beginners POV
</h1>
<span class="text-sm text-gray-500">26th July, 2025</span>
<p class="text-lg font-serif mt-4">
When your web browser fetches this blog post, when your messaging app
sends a text, or when you stream a video, there's a fundamental mechanism
at work, we call it SOCKETS
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/banner.png" class="w-[75%] mx-auto my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-4">
Sockets are the endpoints of communication channels that allow processes
to exchange data, whether they're on the same machine or across the globe.
At its core, a socket is an abstraction provided by the operating system
that represents one endpoint of a bidirectional communication link. The
socket API, originally developed for Unix systems, has become the standard
interface for network programming across virtually.
</p>
<p class="text-lg font-serif mt-3">
Socket operate at different layers of the network stack. TCP sockets
provide reliable, ordered data delivery with error detection and
correction. UDP sockets offer faster, connection less communication
without delivery guarantees
</p>
<p class="text-lg font-serif mt-4">
The socket abstraction hides the complexity of network protocols, hardware
interface and routing decisions. When you create a socket, the operating
systems allocates kernel data structures, assigns network resources, and
manages the connection lifecycle. This abstraction enables developers to
focus on application logic rather than low-level network details.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/abstraction.png" class="my-10 w-[60%] mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-4">
But how do processes on the same machine communicate without going through
the network stack at all ??
</p>
<h1 class="text-2xl font-serif my-7">The Silent Communication Channel</h1>
<p class="text-lg font-serif">
An anonymous pipe is a unidirectional communication channel that exists
only in memory. Unlike named pipes (FIFOs), anonymous pipes have no
filesystem representation and can only be shared between related
processes, typically a parent and its child processes
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/layers.png" class="mx-auto w-[70%] my-10" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif mt-3">
The kernel implements anonymous pipes using a circular buffer, typically
64KB on Linux systems. This buffer acts as a temporary storage area
between the writing and reading processes. When the buffer fills up,
writers are blocked until readers consume data, providing natural flow
control.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
Anonymous Pipes working in C
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"stdio.h"&gt;
#include &lt;"unistd.h"&gt;
#include &lt;"stdio.h"&gt;
int main() {
int pipefd[2];
pid_t pid;
// creating a pipe
if (pipe(pipefd) == -1) {
perror("pipe");
return 1;
}
pid = fork();
if (pid == 0) {
// child process - writer
close(pipefd[0]); // Close read end
write(pipefd[1], "Hello from child", 16);
close(pipefd[1]);
} else {
//parent process - reader
char buffer[20];
close(pipefd[1]); // Close write end
read(pipefd[0], buffer, 16);
printf("Received: %s\n", buffer);
close(pipefd[0]);
}
return 0;
}
</code></pre>
</details>
<p class="font-serif text-lg">
The pipe() system call creates two file descriptors: pipefd[0] for reading
and pipefd[1] for writing. The kernel maintains a circular buffer
(typically 64KB on Linux) between these endpoints. When the buffer fills
up, writers block until readers consume data.
</p>
<p class="font-serif text-lg mt-3">
The creation of anonymous pipes involves the operating system allocating
two file descriptors: one for reading and one for writing. These
descriptors can be inherited by child processes through fork(), enabling
parent-child communication. The pipe exists as long as at least one
process holds either descriptor open.
</p>
<p class="font-serif text-lg mt-4">
Unlike network sockets, pipes operate entirely within kernel memory,
making them extremely fast for local communication. There's no network
protocol overhead, no packet serialization, and no routing decisions just
direct memory-to-memory data transfer managed by the kernel.
</p>
<p class="font-serif text-lg mt-2">
But what exactly are these file descriptors that pipes return, and how
does the operating system manage them?
</p>
<h1 class="text-2xl font-serif my-6">File Descriptors</h1>
<p class="font-serif text-lg">
File descriptors are the answer to our previous question about how the OS
manages communication endpoints. A file descriptor (fd) is a non-negative
integer that serves as an abstract handle for accessing files, sockets,
pipes, devices, and other I/O resources in Unix-like systems.
</p>
<p class="font-serif text-lg mt-3">
The operating system maintains a file descriptor table for each process,
mapping fd numbers to kernel data structures that contain the actual
details about the resource. This indirection allows the kernel to manage
resources centrally while providing processes with simple integer handles.
</p>
<!-- <details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
File Descriptors in C
</summary>
<pre class="font-mono text-sm p-4">
<code class="language-c">#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
int main() {
// Creating different types of file descriptors
// 1. Socket file descriptor
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
printf("Socket fd: %d\n", sockfd);
// 2. File descriptor for regular file
int filefd = open("/tmp/test.txt", O_CREAT | O_RDWR, 0644);
printf("File fd: %d\n", filefd);
// 3. Pipe file descriptors
int pipefd[2];
pipe(pipefd);
printf("Pipe read fd: %d, write fd: %d\n", pipefd[0], pipefd[1]);
// All can be used with same I/O operations
char buffer[100];
read(sockfd, buffer, 100); // Read from socket
read(filefd, buffer, 100); // Read from file
read(pipefd[0], buffer, 100); // Read from pipe
close(sockfd);
close(filefd);
close(pipefd[0]);
close(pipefd[1]);
return 0;
}
</code></pre>
</details> -->
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
File Descriptors in C
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/socket.h"&gt;
#include &lt;"netinet/in.h"&gt;
#include &lt;"unistd.h"&gt;
int main() {
// Creating different types of file descriptors
// 1. Socket file descriptor
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
printf("Socket fd: %d\n", sockfd);
// 2. File descriptor for regular file
int filefd = open("/tmp/test.txt", O_CREAT | O_RDWR, 0644);
printf("File fd: %d\n", filefd);
// 3. Pipe file descriptors
int pipefd[2];
pipe(pipefd);
printf("Pipe read fd: %d, write fd: %d\n", pipefd[0], pipefd[1]);
// All can be used with same I/O operations
char buffer[100];
read(sockfd, buffer, 100); // Read from socket
read(filefd, buffer, 100); // Read from file
read(pipefd[0], buffer, 100); // Read from pipe
close(sockfd);
close(filefd);
close(pipefd[0]);
close(pipefd[1]);
return 0;
}
</code>
</pre>
</details>
<p class="text-lg font-serif">
Whether we are dealing with network socket, a regular file, or a pipe, you
use the same system calls : read(), write(), close(), and others. This
abstraction is what makes Unix-like systems so powerful for system
programming.
</p>
<p class="text-lg font-serif">
File descriptors are process-specific resources. When a process forks, the
child inherits copies of the parent's file descriptors, but subsequent
operations on these descriptors in either process don't affect the other.
However, both processes share the same underlying kernel file description,
so operations like changing file position affect both processes.
</p>
<p class="text-lg font-serif">
The kernel enforces limits on file descriptors to prevent resource
exhaustion. Each process has both soft and hard limits on the maximum
number of open file descriptors. These limits can typically be viewed and
modified using system utilities, and they're crucial for server
applications that handle many concurrent connections.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/kfd.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="font-serif text-lg">
But how do we efficiently monitor multiple file descriptors for activity
without constantly polling them?
</p>
<h1 class="text-2xl font-serif my-7">Managing Multiple Connections</h1>
<p class="text-lg font-serif">
I/O multiplexing solves the challenge of monitoring multiple file
descriptors simultaneously. Instead of creating separate threads for each
connection or constantly polling each descriptor, multiplexing allows a
single thread to wait for activity on multiple file descriptors at once.
</p>
<p class="text-lg font-serif mt-3">
The fundamental problem that I/O multiplexing addresses is the blocking
nature of I/O operations. When a process calls read() on a socket with no
available data, the process blocks until data arrives. For a server
handling multiple clients, this means either dedicating one thread per
connection or missing data from other connections.
</p>
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/multi.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-lg font-serif">
I/O multiplexing enables a single process to efficiently handle multiple
input/output sources, such as sockets, without blocking on each one
individually. The application process communicates with an I/O multiplexer
(e.g., select, poll, or epoll), requesting it to monitor a set of file
descriptors (FDs) in this case, three socket FDs. The multiplexer
continuously checks the status of these FDs and blocks the process until
one or more of them become "ready" (e.g., data is available to read). When
an event occurs on a monitored FD (like FD 1 or FD 3 becoming readable),
the multiplexer returns control to the process with information about
which FDs are ready.
</p>
<p class="text-lg font-serif mt-3">
The process can then perform non-blocking I/O only on those specific
descriptors. This mechanism allows efficient use of system resources by
avoiding the need to spawn multiple threads or processes for each I/O
source.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
epoll() in C
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/epoll.h"&gt;
int epoll_fd = epoll_create1(0);
struct epoll_event event, events[MAX_EVENTS];
// Add socket to epoll
event.events = EPOLLIN;
event.data.fd = socket_fd;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, socket_fd, &amp;event);
// Wait for events
int num_events = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
</code>
</pre>
</details>
<p class="text-lg font-serif mt-3">
I/O multiplexing enables servers to handle thousands of concurrent
connections with a single thread, but what about connections that are
meant to be temporary and don't need to persist?
</p>
<h1 class="font-serif text-2xl my-6">The Temporary Connection Endpoints</h1>
<p class="font-serif text-lg mt-2">
Ephemeral ports provide the answer to temporary connections. When a client
application creates an outbound connection, it doesn't typically specify a
source port. Instead, the operating system automatically assigns an
ephemeral (temporary) port from a predefined range.
</p>
<p class="font-serif text-lg mt-2">
The ephemeral port range varies by operating system. Linux typically uses
ports 32768-60999, while Windows uses 1024-65535. These ranges are
configurable and represent a balance between providing enough ports for
concurrent connections while reserving lower-numbered ports for well-known
services.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
How ephermal ports work in practice
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/socket.h"&gt;
#include &lt;"netinet/in.h"&gt;
#include &lt;"arpa/inet.h"&gt;
int main() {
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in server_addr, local_addr;
socklen_t addr_len = sizeof(local_addr);
// Connect to server (OS assigns ephemeral port automatically)
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(80);
inet_pton(AF_INET, "93.184.216.34", &amp;server_addr.sin_addr); // example.com
connect(sockfd, (struct sockaddr*)&amp;server_addr, sizeof(server_addr));
// Check what ephemeral port was assigned
getsockname(sockfd, (struct sockaddr*)&amp;local_addr, &amp;addr_len);
printf("Local port assigned: %d\n", ntohs(local_addr.sin_port));
close(sockfd);
return 0;
}
</code>
</pre>
</details>
<p class="text-lg font-serif mt-3">
Ephemeral port allocation strategies differ across operating systems. Some
use sequential allocation, starting from the lowest available port in the
range. Others use random or hash-based algorithms to distribute ports more
evenly across the range. The choice affects performance, security, and the
ability to handle high connection rates.
</p>
<p class="text-lg font-serif mt-3">
The lifecycle of an ephemeral port begins when a client initiates an
outbound connection. The operating system selects an available port, binds
it to the socket, and uses it as the source port for the connection. When
the connection closes, the port enters a TIME_WAIT state before becoming
available for reuse.
</p>
<div class="my-10">
<img src="https://mrinalxdev.github.io/mrinalxblogs/blogs/assets/websockets/ephermal.png" class="my-10 mx-auto" alt="" referrerpolicy="no-referrer">
<p class="text-sm text-gray-500 text-center font-serif">
TCP (Transmission Control Protocol) state machine, which outlines the
various states a TCP connection transitions through during its
lifecycle.
</p>
</div>
<p class="font-serif text-lg">
TIME_WAIT is a crucial TCP state that prevents delayed packets from a
closed connection from interfering with new connections using the same
port pair. The typical TIME_WAIT duration is twice the Maximum Segment
Lifetime (MSL), often 60-120 seconds. This can become a limiting factor
for applications making many short-lived connections.
</p>
<p class="font-serif text-lg">
Port exhaustion occurs when all ephemeral ports are in use or in TIME_WAIT
state. This is a common problem for high-traffic proxy servers or
applications making many outbound connections. Solutions include using
multiple IP addresses, tuning TIME_WAIT parameters, or implementing
connection pooling.
</p>
<h1 class="font-serif text-2xl my-6">Raw Sockets and custom protocols</h1>
<p class="font-serif text-lg">
What about scenarios where we need to implement custom protocols or handle
raw network data?
</p>
<p class="text-lg font-serif mt-2">
Raw sockets provide direct access to network protocols below the transport
layer, allowing applications to craft custom packets or implement
protocols not directly supported by the operating system.
</p>
<p class="text-lg font-serif mt-2">
Operating systems typically provide TCP and UDP socket abstractions that
handle most application needs. However, some applications require
lower-level access to implement custom protocols, perform network
analysis, or bypass standard protocol limitations.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
Implementing raw sockets
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">#include &lt;"sys/socket.h"&gt;
#include &lt;"netinet/ip.h"&gt;
#include &lt;"netinet/tcp.h"&gt;
#include &lt;"arpa/inet.h"&gt;
// Creating a raw socket (requires root privileges)
int create_raw_socket() {
int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
if (sockfd &lt; 0) {
perror("raw socket creation failed");
return -1;
}
// Tell kernel not to add IP header (we'll craft it ourselves)
int one = 1;
if (setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, &amp;one, sizeof(one)) &lt; 0) {
perror("setsockopt IP_HDRINCL failed");
return -1;
}
return sockfd;
}
// Craft a custom TCP packet
void craft_tcp_packet(char *packet, const char *src_ip, const char *dst_ip,
uint16_t src_port, uint16_t dst_port) {
struct iphdr *ip_header = (struct iphdr *)packet;
struct tcphdr *tcp_header = (struct tcphdr *)(packet + sizeof(struct iphdr));
// Fill IP header
ip_header-&gt;version = 4;
ip_header-&gt;ihl = 5;
ip_header-&gt;tos = 0;
ip_header-&gt;tot_len = htons(sizeof(struct iphdr) + sizeof(struct tcphdr));
ip_header-&gt;id = htons(12345);
ip_header-&gt;frag_off = 0;
ip_header-&gt;ttl = 64;
ip_header-&gt;protocol = IPPROTO_TCP;
ip_header-&gt;check = 0; // Kernel will calculate
inet_pton(AF_INET, src_ip, &amp;ip_header-&gt;saddr);
inet_pton(AF_INET, dst_ip, &amp;ip_header-&gt;daddr);
// Fill TCP header
tcp_header-&gt;source = htons(src_port);
tcp_header-&gt;dest = htons(dst_port);
tcp_header-&gt;seq = htonl(1000);
tcp_header-&gt;ack_seq = 0;
tcp_header-&gt;doff = 5;
tcp_header-&gt;syn = 1; // SYN flag
tcp_header-&gt;window = htons(65535);
tcp_header-&gt;check = 0; // Calculate separately
tcp_header-&gt;urg_ptr = 0;
}
</code>
</pre>
</details>
<p class="text-lg font-serif mt-">
Raw sockets operate at the IP level or even lower, depending on the socket
type and options. Applications using raw sockets must manually construct
protocol headers and handle details normally managed by the operating
system, such as checksums, fragmentation, and addressing.
</p>
<h1 class="text-2xl font-serif my-6">
Notes on Performance and Optimization
</h1>
<p class="text-lg font-serif">
Buffer management significantly impacts socket performance. The
bandwidth-delay product determines optimal buffer sizes - the product of
network bandwidth and round-trip time indicates how much data should be
"in flight" for maximum throughput. Undersized buffers limit throughput,
while oversized buffers waste memory.
</p>
<p class="text-lg font-serif mt-3">
Connection reuse and pooling strategies reduce the overhead of connection
establishment and teardown. HTTP/1.1 introduced persistent connections to
avoid repeated TCP handshakes. HTTP/2 multiplexes multiple streams over
single connections. Connection pools maintain ready-to-use connections to
frequently accessed servers.
</p>
<details class="my-6 bg-gray-700 text-gray-100 rounded-lg overflow-x-auto">
<summary class="p-4 cursor-pointer font-serif text-lg outline-none">
Connection reusing and pooling
</summary>
<pre class="font-mono text-sm p-4"><code class="language-c">typedef struct {
int *sockets;
int count;
int capacity;
pthread_mutex_t mutex;
} connection_pool_t;
int get_connection(connection_pool_t *pool, const char *host, int port) {
pthread_mutex_lock(&amp;pool-&gt;mutex);
if (pool-&gt;count &gt; 0) {
// Reuse existing connection
int sockfd = pool-&gt;sockets[--pool-&gt;count];
pthread_mutex_unlock(&amp;pool-&gt;mutex);
return sockfd;
}
pthread_mutex_unlock(&amp;pool-&gt;mutex);
// Create new connection
return create_connection(host, port);
}
void return_connection(connection_pool_t *pool, int sockfd) {
pthread_mutex_lock(&amp;pool-&gt;mutex);
if (pool-&gt;count &lt; pool-&gt;capacity) {
pool-&gt;sockets[pool-&gt;count++] = sockfd;
} else {
close(sockfd); // Pool full, close connection
}
pthread_mutex_unlock(&amp;pool-&gt;mutex);
}
</code>
</pre>
</details>
<p class="text-lg font-serif">
Memory mapping can improve performance for applications that repeatedly
access the same data. By mapping files into memory, applications can avoid
system call overhead and benefit from the operating system's virtual
memory management.
|
smart-z
pushed a commit
to smart-z/RSSHub
that referenced
this pull request
Jan 18, 2026
Co-authored-by: Mike Chen <yang.chen.mike@gojek.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Involved Issue / 该 PR 相关 Issue
Close #
Example for the Proposed Route(s) / 路由地址示例
New RSS Route Checklist / 新 RSS 路由检查表
PuppeteerNote / 说明