I just finished a project where we were hitting an internal database - large dataset, reads happening constantly, the kind of workload where every extra millisecond compounds into something users actually feel. At some point I stopped tuning blindly my application code and asked myself a question : what actually happens between the moment my application sends a query and the moment rows come back?

I had a rough idea. But rough don't tell you why adding an index sometimes does nothing. They don't tell you which of the five layers your query is getting stuck in. My philosophy has always been the same - you can't optimize what you don't how background processing is working in the first place. Find how the thing actually works, find the gaps, fix the gaps.

You write a query. You hit enter. Data comes back.

I stopped there. I got what what i needed, move on. But that "hitting enter" part? There's a lot happening underneath it that most people never bother to understand and until this point neither do i - and that's fine, until queries get slow or production breaks and you have no idea where to even start looking - it comes with experience.

I've seen engineers with years of experience stare at a slow query and just add more hardware. Sometimes that works. Usually it doesn't. Because the problem wasn't resources - it was that the database chose a bad plan, or there was no index, or someone didn't wrap two writes in a transaction. Things you'd catch instantly if you understood what happens after you hit enter.

The Query

SELECT name, age FROM users WHERE city = 'Kolkata';

Simple enough. But the path this takes inside the database isn't simple at all. There are at least five distinct layers it passes through, each doing something completely different. Miss any one of them and you're working with an incomplete model. Incomplete models lead to wrong assumptions. Wrong assumptions lead to 3am incidents which i had past experiences with.

Step 1 - Transport Layer

Before the database reads a single character of your SQL, it first has to receive it.

Your application sends the query over TCP. Raw bytes. The database is listening on a port - 5432 for Postgres, 3306 for MySQL - and receives those bytes according to a wire protocol. Postgres has its own. MySQL has its own. They're not interchangeable, which is why your MySQL driver doesn't work against a Postgres server and gives you an error that feels completely unrelated to the actual problem.

Authentication happens here too. The database checks your credentials, then checks whether your user has SELECT permission on the table you're querying. If not, the query dies right here. Doesn't even get parsed.

Now, something a lot of junior engineers don't think about: opening a TCP connection costs real time. You've got the three-way handshake, memory allocation on the server side, thread assignment - it adds up. If your application opened a fresh connection for every single query, you'd spend more time connecting than actually running SQL. This is why connection pooling exists.

# The pool is created once when your app starts
pool = psycopg2.pool.ThreadedConnectionPool(minconn=5, maxconn=20, dsn="...")

# Every request borrows a connection that's already open
conn = pool.getconn()

I've seen applications that weren't using a connection pool go from 800ms average query time down to under 50ms just by adding one. The queries themselves didn't change. The database didn't change. Just stopped paying the connection overhead on every request. It's one of those fixes that feels too simple to be real until you see the numbers.

Step 2 - The Query Processor Layer

This is where most of the work happens. There are four distinct things happening inside it, and collapsing them into one is how people end up with broken mental models that don't help when something actually goes wrong.

Parsing

The parser reads your SQL as plain text and decides whether it's even valid. It doesn't know your tables, doesn't know your schema, doesn't care about any of that yet. It just checks whether the words and symbols you wrote form a legal sentence in SQL's grammar. A misplaced comma, a typo in a keyword, a quote you forgot to close - any of it stops everything cold.

SELCT name, age FORM users WHERE city = 'Kolkata';
-- ERROR: syntax error at or near "SELCT"

Nothing else runs. Not the semantic check, not the optimizer. Just an error.

If the syntax is valid, the parser produces a parse tree - your query represented as a data structure instead of text. The SELECT is the root. The column list, the FROM, the WHERE - each becomes a node. That tree is what every other step works from. You never see it. But every query you've ever written turned into one the moment you hit enter.

The Semantic Analyzer - missing from the original diagram

The parser said the sentence is grammatically correct. The semantic analyzer asks whether it actually means anything.

It goes to the system catalog - the database's own internal record of everything that exists in it, every table, every column, every type - and checks whether the things you named are real. Does a table called users exist? Does it have a column called name? Is city a text column, or something else you can't compare to a string?

-- Valid syntax, fails semantic analysis
SELECT name, age FROM users WHERE city = 'Kolkata';
-- ERROR: relation "users" does not exist

That error you've seen a hundred times - relation does not exist, column does not exist - that's this step catching a typo before anything else runs. The reason it's separate from parsing is that the parser has no idea what tables you have. It only knows grammar. The semantic analyzer is the part that connects the words in your query to real objects in your database. Once I understood this, those errors stopped feeling cryptic. They're just the catalog saying "I checked, and that thing isn't here."

The Rewriter

Once semantics pass, the query may be rewritten into a different form before optimization begins.

The clearest example is views. When you query a view, the database doesn't run the view separately and combine the results. It expands the view's definition directly into your query before the optimizer sees anything at all.

-- Assume you defined this earlier
CREATE VIEW active_users AS
    SELECT * FROM users WHERE status = 'active';

-- You write this
SELECT name FROM active_users WHERE city = 'Kolkata';

-- The rewriter turns it into this before anything else happens
SELECT name FROM users
WHERE status = 'active' AND city = 'Kolkata';

The optimizer never knows a view was involved. It just gets a clean query against a real table. This is actually reassuring once you know it - it means using a view doesn't cost you anything at the query level. The abstraction is free. The rewriter handles the expansion silently so the optimizer never has to reason about indirection.

There's other work it does too - flattening subqueries, pushing conditions closer to where the data lives, simplifying things that evaluate to constants. Most of it you'll never notice, which is exactly the point.

The Query Optimizer - the most important step

If you understand nothing else from this article, understand what the optimizer does.

The optimizer takes the rewritten query and figures out the best way to actually run it. Not just one way - it generates multiple candidate plans, estimates the cost of each, and picks the cheapest one. The cost isn't wall-clock time directly. It's a proxy - in Postgres, roughly the number of disk page reads the plan is expected to require. Low cost means fewer reads, which usually means faster.

SELECT name, age FROM users WHERE city = 'Kolkata';

Two obvious plans for this:

Option A - Sequential Scan
Scan every page in the users table.
Filter rows where city = 'Kolkata'.
Cost estimate: 42.7

Option B - Index Scan on city_index
Walk the B+Tree index on the city column.
Read only the pages containing matching rows.
Cost estimate: 0.04

Both give you the same rows. The cost difference is roughly 1000x. The optimizer picks Option B.

Those estimates come from statistics the database keeps about your data - how many rows exist, how many distinct values each column has, how the values are distributed. When those statistics are fresh and accurate, the optimizer makes good choices. When they're stale - say, your table grew by an order of magnitude since the last time stats were collected - the optimizer is working from a picture of your data that no longer looks like your actual data. It picks a plan that seemed reasonable based on what it knew. You feel the result as a query that used to be fast and suddenly isn't, with no obvious explanation.

EXPLAIN shows you which plan it chose:

EXPLAIN SELECT name, age FROM users WHERE city = 'Kolkata';

-- Index Scan using users_city_idx on users
--   Index Cond: (city = 'Kolkata')
-- Planning Time: 0.3 ms

Seq Scan where you expected Index Scan means the optimizer didn't use your index - either because it doesn't exist or because outdated stats made a full scan look cheaper. Running EXPLAIN ANALYZE instead of plain EXPLAIN actually executes the query and shows you real row counts next to the estimates. That gap, when it's large, is usually the explanation for whatever you're debugging.

I run EXPLAIN on every non-trivial query before it ships. Not because I distrust the optimizer, but because there's a big difference between thinking a plan will be good and confirming it is. The number of times those two have disagreed on me is higher than I'd like to admit.

Step 3 - The Execution Engine

The optimizer chose a plan. Now something has to actually run it.

The execution engine walks the plan tree and carries out each operation in order - index scan, key lookup, filter, sort, whatever the plan calls for - passing rows from one step to the next like a relay. It's not doing anything clever. The clever part already happened. The execution engine just follows instructions.

For our query, it goes like this:

1. Walk the city_index B+Tree to find rows where city = 'Kolkata'
   → Returns tuple IDs (row pointers)

2. For each tuple ID, fetch the actual row from the table heap
   → Reads name, age off the page

3. Stream rows back up the call stack

That second step - going back to the table to get columns that aren't in the index - is called a heap fetch. It's easy to miss because the index lookup feels like the whole thing. But the index only stores what you indexed, plus a pointer. Anything else has to be fetched separately. On our project, we had implemented the right index on the filter column. The queries were still slower than they should have been. That was the heap fetch - thousands of extra page reads per second that nobody had thought about because the index itself felt sufficient.

Adding those two columns to the index fixed it. A covering index - one that includes every column the query needs - means the execution engine never has to leave the index at all. The difference in something read-heavy is hard to miss once you've seen it. It has its own drawbacks.

Step 4 - The Storage Engine

The execution engine doesn't touch disk directly. It calls down into the storage engine, which handles everything at the physical level - pages, memory, concurrency, crash recovery.

Four things live here that are worth actually understanding.

First is the buffer manager : Databases don't read individual rows off disk. They read pages - fixed-size blocks, 8KB in Postgres. The buffer manager keeps a pool of recently-used pages in memory. If the page you need is already there, you get it from RAM and it's fast. If it isn't, the buffer manager reads it from disk, caches it, and keeps it warm for next time. This is why the same query often runs faster on the second call - the first one paid the disk cost and left the pages where the second one could find them. On our project this was immediately visible. Cold-start query times were a different world from what the same queries did after the system had been running under load for a few minutes. The buffer pool was the difference.

Then there's the lock manager : Reads can happen in parallel - shared locks don't conflict with each other. Writes can't. A write needs an exclusive lock on the row, which means waiting for every existing reader to finish and blocking any new ones until the write is done. One writer, or many readers, never both at once. Without this the database would let two concurrent updates race against each other, and whoever wrote last would quietly undo the other one. No error, no warning, just a number that's wrong.

The transaction manager is what makes writes safe across multiple statements. Take this:

BEGIN;
    UPDATE accounts SET balance = balance - 500 WHERE id = 1;
    UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;

If the database crashes after the first UPDATE but before COMMIT, neither change survives. Both rows go back to their original values when the database restarts. The transaction manager sees the uncommitted transaction in the log and rolls it back. Nothing half-applied, nothing missing.

Without that BEGIN wrapped around both writes - if someone just ran them as two standalone statements - a crash between them leaves one account debited and the other unchanged. I've seen this in real production code. The person who wrote it thought the two statements were close enough together that the risk was negligible. It usually is. Until it isn't.

Last is the recovery manager. Every change is written to the Write-Ahead Log - an append-only log file - before it's applied to the actual data. That's sequential writes, which are fast. On a crash, the database replays the WAL on startup and reconstructs anything that was committed but hadn't been flushed to the data files yet. The system call that actually persists the WAL to physical storage is fsync. Turn it off and you get better throughput, but a crash can take commits with it that the application already acknowledged as successful. Some workloads accept that tradeoff - they care more about speed than strict durability. Most production databases shouldn't. The gap between "I turned off fsync knowingly" and "I turned off fsync because I read it was faster" is a postmortem waiting to happen.

So what

Add indexes on columns you filter by. Without one, the optimizer has no choice but to scan the whole table - not because it's dumb, because there's literally nothing faster available to it.

Run EXPLAIN before you ship any query that'll run against real data at scale. Doesn't take long. Tells you exactly what the optimizer decided. The plan you assumed it would use and the plan it actually chose are sometimes the same. Not always.

EXPLAIN ANALYZE SELECT name, age FROM users WHERE city = 'Kolkata';

-- Seq Scan   → missing index or stale stats
-- Index Scan → optimizer found it, you're probably fine
-- big gap between estimated rows and actual rows → run ANALYZE

Wrap related writes in transactions. Both updates or neither - not whichever one made it before the server decided to restart.

Stop reaching for more hardware when a query is slow. Hardware helps a working system carry more load. It does almost nothing for a query running the wrong plan. A missing index is still a missing index on a faster machine - you just pay more per slow request.

Most performance problems I've seen in databases weren't hardware problems. They were a missing index, estimates the optimizer was making from statistics that no longer reflected the data, or a transaction boundary someone forgot to draw. All three are findable once you understand what actually happens after you hit enter. That's the whole reason to know this. Not the theory for its own sake - the ability to sit down with a slow system and have a real idea of where to look.

Let's fix this forever with two tools: Git and GitHub.

Part 1: Git - Your Personal Time Machine ⏳

Imagine Git as a "save game" system for your code. It runs on your local machine and keeps a complete history of every change you make. You can mess things up, experiment freely, and always revert to a previous working version.

The 3 Core Commands

Let's say you've started a new project.

1. Initialize Git: Go to your project folder in the terminal and run:

    # This creates a hidden .git folder to track everything
    git init
   

2. Add Files: You've created a file, say index.html. Now, tell Git you want to track it.

    # The '.' means "add all files in this folder"
    git add .
   

3. Commit Changes: This is your "save point." You lock in the changes with a descriptive message.

    git commit -m "Create initial index.html file"
   

That's it! You've made your first commit. You now have a snapshot of your project you can return to at any time.

Part 2: GitHub - Your Code's Cloud Home ☁️

If Git is the tool, GitHub is the place where you store your projects online. It's your cloud backup, your portfolio, and your collaboration hub. It lets you share your Git "save points" with the world or your team.

The Magic Workflow ✨

Here’s how Git and GitHub work together.

1. Create a Repo on GitHub: First, create a new, empty "repository" (repo) on GitHub.com.

2. Link and Push: On your local machine, link your project to the GitHub repo and "push" your commits to it. GitHub will provide you with the exact commands to copy and paste, which usually look like this:

    # Links your local project to the GitHub URL (you only do this once)
    git remote add origin [YOUR_GITHUB_REPO_URL]
   
    # Sends your committed changes to GitHub
    git push -u origin main
   

Now, anyone can see your code online! When you make more changes, the process is just two steps:

# 1. Save your changes locally
git commit -m "Add new feature"

# 2. Push them to GitHub
git push

Overview:

Prompt Caching is technique where the System stores the repetitive sentences/words from our Prompts to save time and Cost.

1. Mainly the prompts contain mostly the same words - so prompt caching stores the repetitive parts of the Prompt.

2. When we send the same prompt again - System recognizes the repetitive words and instead of reprocessing them - it uses the stored version.

Benefits of Prompt Caching:

1. Faster API Response as the LLM doesn’t have to process all words.

2. Lower Cost (Since the LLM requires less processing power because the repetitive words are not processed again)

It's like giving the model a "memory" of previous computations, allowing it to quickly retrieve and use that information.

I was curious about “system recognizes “part that how the LLM able to recognize these repetitive words without processing it. Below are the few methods which followed by LLM for Prompt Caching

• Exact Prefix Matching:

  • How it works: The system looks at the beginning (the prefix) of the incoming prompt. It compares this prefix, token by token, with prefixes it has already processed and stored in its cache from recent requests.

  • Recognition: If the entire sequence of tokens at the beginning of the new prompt exactly matches a sequence stored in the cache, it's a "cache hit." The system recognizes that this part doesn't need reprocessing.

  • This is used by providers like OpenAI and Anthropic.

  • Example:

    • Cached Prompt Prefix: "System: You are a helpful assistant. User: Analyze this document: [long document text]"

    • New Prompt: "System: You are a helpful assistant. User: Analyze this document: [long document text] User: Now summarize the key points."

    • Recognition: The system sees that the beginning of the new prompt is identical to the cached prefix up to the end of the document text. It recognizes this match.

  • Why it works: This method is simple and efficient. It guarantees that the reused part is identical, ensuring the model's state is consistent. However, even a tiny change (like a single different character or extra space) in the prefix will break the match ("cache miss").

• Cryptographic Hashing (Often used internally for cache keys):

  • How it works: While not the primary recognition method for the content itself during comparison, hashing is often used to create unique identifiers (cache keys) for the stored prefixes. The system calculates a unique digital fingerprint (a hash) for the sequence of tokens in the cacheable prefix.

  • Recognition: When a new request comes in, the system calculates the hash for its prefix. It then quickly checks if a cache entry with that exact same hash exists. If it does, it means the content is identical.

  • Benefit: Hashing is very fast for looking up whether an exact match exists in a large cache. It also helps ensure data privacy, as the system deals with hashes rather than the raw text directly for lookup.

• Semantic Similarity (Less common for direct prefix caching, more for related concepts):

  • How it works: This is more advanced and less commonly used for the strict "prefix caching" we've discussed, but related concepts exist (like GPTCache mentioned in one of the articles). Instead of looking for an exact match, the system might use techniques like vector embeddings to determine if a new prompt is semantically similar (i.e., has a similar meaning) to a cached one.

  • Recognition: If the meaning is close enough (above a certain threshold), it might retrieve a related cached response or state.

  • Caveat: This is generally not how standard prompt prefix caching works in major APIs like OpenAI or Anthropic for cost/latency reduction, as they rely on exact matches to guarantee identical processing states. Semantic matching is more complex and might be used in different types of caching systems.

Prompt Caching in Different Platforms:

• OpenAI: Automatically enabled for prompts longer than 1024 tokens. Static content should be at the beginning of the prompt for optimal caching. Prompt caching - OpenAI API

• Anthropic: Allows you to cache specific parts of prompts using the cache_control parameter. They emphasize placing static content at the beginning of the prompt. Prompt caching - Anthropic API

• Amazon Bedrock: Implements caching with "cache checkpoints" to mark the beginning of the cacheable section. Prompt caching for faster model inference - Amazon Bedrock

Example

Let's say we declare:

a = 2
print(type(a))  # This will give INT as a response

a = 2
a = "Hello World"
print(type(a))  # This will give String as a response

This is where the interest pops up that a was initially an INT but suddenly converted to a String.

How it works

It uses objects when assigning values to variables and it does it at runtime.

• When we say a = 2:

  • At runtime, it creates an object of INT and assigns the value of 2 to that object.

  • It increments the reference count by 1.

  • It assigns the reference of that object to the a variable.

• When we reassign "Hello World" (a string value) to a:

  • In the background, it creates another object of String with the value "Hello World" assigned to it.

  • It increments the reference of the new object's count by 1.

  • The reference of this newly created object is assigned to the a variable.

  • The reference count for the INT object decreases by 1.

When the reference count of an object hits 0, it becomes eligible for garbage collection. At runtime, the Python garbage collector collects the INT object as it doesn't have any references and the reference count is set to 0.

Ever wondered how traditional loops differ from those cool higher-order array functions in JavaScript? Allow me to share a surprising revelation I stumbled upon while diving into arrays.

I used to think that traditional for loops and higher-order array functions like forEach were just two sides of the same coin—different syntax, same functionality. But here's the twist: their handling of the return statement sets them apart.

In the realm of forEach, the return statement exits only the callback function passed to it, not the entire surrounding function. It's like a 'skip' button for that specific iteration.

javascriptCopy codeconst numbers = [1, 2, 3, 4, 5];

numbers.forEach((number) => {
  if (number === 3) {
    return; // Skips iteration when number equals 3
  }
  console.log(number);
});

// Output: 1, 2, 4, 5

On the flip side, a return statement in a traditional for loop exits the entire enclosing function. This is because in a for loop, return directly affects the function scope, unlike in a forEach loop.

But wait, if you're thinking of using return to stop a forEach loop altogether, hold that thought! You'll need to explore methods like Array.prototype.some() or Array.prototype.every() to achieve similar functionality. These methods gracefully halt iteration when certain conditions are met.

Understanding these nuances can be a game-changer, especially when fine-tuning your code for specific behaviors or conditions. Have you encountered similar surprises while working with JavaScript arrays? Do Share your thoughts!

Further Reading if One Interested:

1. MDN Web Docs - Array.prototype.forEach(): Link

2. MDN Web Docs - Array.prototype.some(): Link

3. MDN Web Docs - Array.prototype.every(): Link

4. JavaScript.info - Array Methods: Link

5. Medium Article - Understanding JavaScript’s forEach(): Link.

1. Physical Level: This is the lowest level of data abstraction and deals with how data is stored in memory. It involves access methods (sequential or random) and file organization methods (e.g., B+ trees or hashing). Details such as storage blocks and memory usage are hidden from the user. For example, when storing employee details, the specifics of storage and memory are kept hidden.

2. Logical Level(Conceptual): This level represents the actual data stored in the database in the form of tables and defines the relationships between data entities. It provides a relatively simple structure for storing information. The information available at the view level is unknown at this level. Attributes of an employee and relationships (e.g., with the manager) can be stored at the logical level.

3. View Level: This is the highest level of abstraction, which allows users to interact with the database by viewing a specific part of it. Users can access data in the form of rows and columns using tables and relations. Multiple views of the same database may exist. The view level exists to make the database easily accessible to individual users, hiding storage and implementation details.

The main purpose of data abstraction is to achieve data independence, which saves time and costs when modifying or altering the database. Data independence allows changes to be made at one level of the system without affecting the schema at the next level. There are two types of data independence:

1. Physical Level Data Independence: This refers to the ability to modify the physical schema without affecting the conceptual or logical schema. It allows optimization changes, such as using new storage devices, modifying data structures, altering indexes, or changing file organization techniques.

2. Logical Level Data Independence: This refers to the ability to modify the logical schema without affecting the external schema or application programs. Changes can include inserting or deleting attributes, altering table structures, or modifying entities and relationships in the logical schema.

By providing data independence, database systems allow for flexibility and easier maintenance as different levels of the system can be modified independently.

What is Consistent Hashing?

Consistent hashing is a technique used to distribute data evenly across multiple servers in a cluster. It is an algorithm that maps each data item to a point on a ring or a circle, and the servers are also mapped to points on the same ring. Each server is responsible for storing and serving the data that falls within the range between it and its neighbouring server on the ring.

Here's how it works:

1. Imagine a circle or a ring. Each point on the circle represents a server.

2. You use a hash function to map each server's IP address (or some other identifier) to a point on the circle.

3. You also use the same hash function to map each piece of data to a point on the circle.

4. Each piece of data is then assigned to the server that is closest to it on the circle (either clockwise or counterclockwise).

5. Now, let's say you want to add a new server. You just need to map its IP address to a point on the circle, and then move some of the data that was assigned to its neighbouring servers over to the new server. This way, the load is distributed evenly across all the servers.

6. If a server goes down, you just need to move its data to the server that is closest to it on the circle. Again, this ensures that the load is distributed evenly.

For more visual explanation: https://youtu.be/oKAU6LaYFhw

Consistent Hashing Benefits

Consistent hashing offers several benefits in distributed systems, including:

1. Scalability: Consistent hashing allows for easy scaling of a system. When a new server is added to the cluster, only a fraction of the data needs to be moved around to balance the load. This makes it easy to add and remove servers without disrupting the entire system.

2. Load Balancing: Consistent hashing evenly distributes data across multiple servers, ensuring that each server gets an equal share of the load. This helps to prevent the overloading of any single server and ensures that the system can handle a large number of requests without slowing down.

3. Fault Tolerance: Consistent hashing is fault-tolerant. If a server fails, the data it was responsible for can be easily moved to a neighbouring server without affecting the rest of the system. This ensures that the system remains available even when individual servers fail.

4. Caching: Consistent hashing can be used to cache data efficiently. The data can be cached on the server that is responsible for it, ensuring that the cache is always up to date.

Use Cases of Consistent Hashing

Consistent hashing is used in a variety of distributed systems, including:

1. Distributed Databases: Consistent hashing is widely used in distributed databases. It allows for easy scaling of the database, load balancing, and fault tolerance.

2. Content Delivery Networks (CDNs): CDNs use consistent hashing to distribute content across multiple servers around the world. This ensures that the content is delivered quickly and efficiently to users.

3. Distributed Caching: Consistent hashing is used to distribute cached data across multiple servers. This ensures that the cache is always up to date and that the load is evenly distributed across the servers.

4. Load Balancers: Load balancers use consistent hashing to distribute requests across multiple servers. This ensures that each server gets an equal share of the load and prevents the overloading of any single server.

5. Peer-to-Peer Networks: Consistent hashing is used in peer-to-peer networks to distribute data across multiple nodes. This ensures that each node gets an equal share of the data and that the load is evenly distributed across the network.

Pitfalls of Consistent Hashing

Although consistent hashing is designed to evenly distribute the load across multiple servers, it can still lead to some issues in certain scenarios. Here are a couple of pitfalls to be aware of:

1. Load Imbalance: Although consistent hashing is designed to evenly distribute the load across multiple servers, it can still lead to load imbalance in certain scenarios. This can happen when there are too few servers in the cluster or when the hash function is not uniform.

2. Hotspotting: Hotspotting is a phenomenon that occurs when a particular data item is accessed frequently, causing a disproportionate amount of traffic to a single server. Consistent hashing can exacerbate this problem by directing all traffic for a particular data item to a single server.

   To avoid these pitfalls, it is important to carefully design a consistent hashing algorithm and tune it for the specific use case.

Conclusion

Consistent hashing is a powerful technique for distributing data evenly across multiple servers in a distributed computing environment. It offers several benefits, including scalability, load balancing, fault tolerance, and caching. Consistent hashing is widely used in distributed databases, CDNs, distributed caching, load balancers, and peer-to-peer networks. However, it can still lead to load imbalance and hot-spotting in certain scenarios, so it is important to carefully design a consistent hashing algorithm and tune it for the specific use case.

Let & Const

As Js already has some reputation for being complicated language so I will try to explain the different types of keywords we used for variable declaration first & why use one over another.

So in ES6, ECMAScript Introduces Let & Const keywords for defining variables.

First, we have to understand the different types of scoping in JS. We have three variations here

• Block Scope: This scope restricts the variable that is declared inside a specific block,(if else, switch, loops) from access by the outside of the block.

• Functional Scope: When a variable is declared inside a function, it is only accessible within that function and cannot be used outside that function.

• Global Scope: As the name suggests, all variables declared in this scope can be accessed globally without restriction.

Declaring variables with 'Let' & 'const' keywords, facilitates the variables to be block scoped.

Variables declared with the var keyword, do not have block scope.(Global)

If you declare a variable using let/const within block means an if-else statement or switch statement or loops, then that variable becomes blocked scoped. But if you declare the same variable within a function that makes it function-scoped.

Then comes Const, as the name suggests this keyword we use to make variable constant so we or the program itself doesn't change the value of that variable accidentally. Const is also a blocked scope variable as mentioned before.

Const is also mutable

But declaring variables with const, we have one caveat i.e const is mutable. So if you are declaring an array or object using const we will be able to modify the content within. But how's that even possible when const only works to prevent mutation? Actually, const does prevent modification by creating a read-only reference to a value. It does not mean the value it holds is immutable—just that the variable identifier cannot be reassigned means you can't reinitialize the whole array/obj.

Arrow Functions

ES6 introduced a new way of declaring functions. First, we will see what a normal function looks like & then we will convert it to an arrow function so you can do it too.

//normal function 
function traditionalFunction(name) {
  console.log(`Hello Developer, ${name} !!!`);
}
traditionalFunction('Abhisekh');

Arrow Function :

const arrowFunction = (name) => {
  console.log(`Hello Developer, ${name} !!!`);
};
arrowFunction('Abhisekh');

Arrow some new differences with normal functions which you may like

• if you are taking one argument in your function then you don't need to include (). (It makes the code looks nice IMO). You only need to add parenthesis when you are working with more than one argument.

• if your function doing one-liner work & returning the value, then you don't need to return as well curly braces({}).

• The biggest functional differences are that arrow functions do not have their own this binding or prototype and cannot be used as a constructor.

• Arrow functions don't have a constructor or prototype.

Example :

• without parenthesis & return

    const arrowFunction = name => `Hello Developer, ${name} !!!`;
  
    console.log(arrowFunction('Abhisekh'));
  

• ArrowFunction doesn't have a prototype & Constructor

    const myArrowFunction = () => {}
  
    // Attempt to log the prototype property of myArrowFunction
    console.log(myArrowFunction.prototype) //this will give undefined
  
    const arrowInstance = new myArrowFunction()
  
    console.log(arrowInstance) // this throw typeError saying it is not a constructer but it will not happen with function as they supports constructer & prototype.
  

  Rest Operator

• The JavaScript spread operator (...) allows us to put the rest of some specific user-supplied values into a JavaScript array.

• A function definition can only have one rest parameter, and the rest parameter must be the last parameter in the function definition.

• The console would display the strings You have passed 3 arguments. and You have passed 4 arguments..

• The rest parameter eliminates the need to check the args array and allows us to apply map(), filter() and reduce() on the parameters array.

  Note: Beware! You Cannot Use “use strict” Inside a Function Containing a Rest Parameter

    const spreadFuntion = (...args) =>'You have passed ' + args.length + ' arguments.';
  
    console.log(spreadFuntion(0, 1, 2));
    console.log(spreadFuntion('string', null, [1, 2, 3], {}));
  

  Conclusion

  So these are the few new features that ES6 introduced. There is a lot to cover. But I try to outline some of the most important ones which I usually find myself using.

  Thank you for reading.

  If you want to explore here are some links.

• GitHub - ECMAScript 6

• ECMAScript 6: New Features: Overview and Comparison (es6-features.org)

The scalability of an application can be measured by the number of requests it can effectively handle in a given time frame.

When your website grows in popularity and getting more incoming traffic than normal, to support simultaneous amount of request which are expected(and unexpected), we need more resources(CPU, RAM, GPU power) to handle those request.

1. Vertical Scaling :

   One way of tackling is increasing the resource of an existing machine to such extent so it can handle large amounts of requests easily. This technique of scaling is called Vertical Scaling. This kind of scaling is good when you are just getting started because it provides simplicity and low latency. The reason for low latency is all of components of the website resides in one machine which makes the API/DB calls much faster as we don't need to perform network calls.

   But as your incoming traffic increases you have to increase the resources as well, but we have certain hardware limits beyond which we can't upgrade our existing machine. Currently we have 24TiB RAM(which I guess is highest at the time of writing) machine provided by amazon. For more info.. But this high resourced compute machines comes at a very high cost.

2. Horizontal Scaling :

   To resolve the above problems(high cost/hardware limit) instead of putting all the resource into one machine, we are putting multiple machine with normal resources, so that we can handle any amount of request without worrying of hardware limitation. When traffic grows we can simply add more servers(& vice versa) and the website will run smoothly. We can simply achieve this using "autoscaling" feature on AWS.

   But the catch with vertical scaling is, we need to implement load balancer which can distribute the traffic equally among all the machines and have to make our web servers(machines) stateless to able to provide responses to user from any machine irrespective of what machine it was logged in first.

   What do I mean by stateless ?

   If you have build any web application with some authentication or used cookies for storing particular information about the user for a constant time. Typically when you using a cookies for a particular session(user), these details reside with in that machine only. So let's say if a user performs logging in ServerA but due to huge request load balancer redirects the same user to another ServerB after login succed. But this ServerB doesn't have any knowledge about the session created in ServerA. So then ServerB again asks user to login. If you have 'n' machines then in worst case the user have to login in every machine(n) to use the application which is very bad User experience.

   To mitigate the above problem stateless approach comes handy.

   In this approach when a user logs in or done something, we are keeping track of the whole session in a separate database. (preferably NoSQL for Key-Value and simplicity and low latency). So every time request comes from a particular user, web server first checks the the DB for session details and responds accordingly.

   Now after stateless implementation, UserA performs login in ServerA and when login succeeded it stores all the needed details to the database(like userId:{session_details}). Then due to high load, load balancer redirects UserA to ServerX. But this time ServerX goes first to DB and look through the session if it finds user logged in then it will redirects user to home/product page.

   So in that way if we implement Vertical Scaling, each request will be independent of which machines it is was logged in or performed some actions as we keeping global track of the session via DB. So we can add as many machines we want to.

The best possible solution will be mixture of both Vertical & Horizontal Scaling. We can add multiple machine with medium resources to handle incoming traffic with stateless architecture.

Let me know your thoughts on it. Will love to discuss any further addition/feedback about this post.

Ending with a quote :

"Design is not just what it looks like and feels like. Design is how it works." - Steve Jobs

A journey of thousand miles starts with a single step.

Building a complex system which is scalable, provides fault tolerance with other cool stuff also starts with something very simple.

1. Single Server Set Up :

   First we will be starting off with single server means there will be only two component, One is Server and another is Client that's all. If you are thinking about where will be databases, the database will also reside within the server.

   So when client request to the server, server fetches the relevant data from it's internal DB and compute within the server and responds back with a adequate response. But as you can see, we are having a big problem here with this set up and that is Single Point Of Failure(SPOF). Simply put if your server goes down then your entire website goes down with it and if worse that your server's DB got corrupted then you will lose all the data and many cases it is unrecoverable.

2. Individual machine for Server & Database :

   To mitigate the above scenario, we can separate the Server and Database into different machine(VMs). Then all traffic will be going through Server and whenever it needs some data from DB it can access it over a network call. By implementing this infrastructure, we can scale our Server and Database independently. So if your website is getting lots of traffic, you can just add more VMs to the server and vice versa.

3. There are two types scaling : *

   • Vertical Scaling : If we are adding more resource(CPU,RAM,GPU) to one machine only then it's called vertical Scaling. As your loads increase the you will be adding more and more resource to one machine only. But there is hardware limit we need to think of in this scenario as currently one machine can only have limited amount of resource.

   • Horizontal Scaling : Instead of adding more resource to one machine, we adding multiple machine with required amount of resource as Server. So as the load increases we will be only adding more machine as a Server.

   Ideal Solution for scaling will be hybrid of Vertical & Horizontal scaling where we adding machines with medium resources when the traffic increases. We will talk about pros and cons of VS & HS in some other article.

4. Load Balancer :

   The need of load balancer increases as we scaling our servers because when the traffic increases we need to ensure that all the traffic aren't going to only one server. In that case due to overload, the server's response time will be increases and eventually crashes.

   A load balancer is machine itself whose work is to evenly distributes incoming traffic among all web servers that are defined in the load balancer set.

   So, lets see how load balancer works behind the scene.

   Normal Flow :

   When a client goes to website and hit a domain name(eg. https://abhisekh.in) then the first thing happens is your machine send a DNS request to DNS server asking what is the IP of the "https://abhisekh.in". Once DNS provides the IP(Server IP), then browser sends an HTTP request to that IP and that IP(which is the server itself) react with a valid response. This is how normal website works. But if we are using load balancer then there will be another level in between of DNS and the actual web server.

   Load balancer Flow :

   

   Client hits a domain name, DNS request goes to DNS server and DNS server responds with the IP of the load balancer then your browser hits the load balancer then the load balancer sees the request & redirects your request to one of the web server and then web server receives the request & send a response to load balancer and then it forward that response to you.

   To keep the security tight, we should place the web server in the private network(local) of the load balancer so only load balancer can access over private IP and not exposed to outer world. Private IPs are IP addresses which are reachable only between machines within same network.

To keep the article short, we will be discussing other fundamentals in upcoming blogs. (eg : How to handle database failures, Cache, CDN etc..)

Additional Study Material : Load Balancer in Depth

RPA technology can automate back-office tasks, data entry, data validation, and many other labor-intensive tasks, without having to modify their existing IT architecture, firms can automate their digital processes across numerous applications and systems using RPA.

By Implementing RPA across a wide range of businesses and processes, Companies now creating new efficiencies and freeing employees from repetitive monotony and focusing the human workforce more on creative task.

The automated application can be anything from a web based application to Desktop application(like SAP,JDE) or legacy systems that don't have APIs, virtual desktop infrastructures (VDIs), or database access.

Employees with minimal to no programming expertise can be rapidly trained to use RPA tools. The entire project is based on the RPA chart, which allows a flowchart designer to graphically link, drag, and drop icons to represent process phases.

These automation Softwares works in Top-Down approach and it's follows sequential execution unlike JS(Promise hell :( .

Reasons for using this technology :

1. RPA eliminates manual errors, allowing employees to focus on more strategic tasks.

2. RPA does not necessitate programming knowledge. Employees with any topic expertise can be rapidly trained to use RPA tools.

3. RPA robots are less expensive than a full-time human, hence a business can save up to 30% of its total costs by automating repetitive tasks.

4. If you want to learn RPA technology and be a RPA developer, then Average salary of RPA Dev in India is : 4 Lak to 14 Lakh per annum which is pretty good.