DEV Community: Arnav Sharma

How End-to-End Encryption Really Works: Understanding the Diffie–Hellman Key Exchange

Arnav Sharma — Sun, 12 Oct 2025 09:06:58 +0000

Every time I hear a service proudly claim “We’re end-to-end encrypted”, I can’t help but wonder:

How do they actually share their encryption keys?

Think about it — when you send a message on WhatsApp or Signal, your phone and your friend’s phone somehow end up using the same secret key to encrypt and decrypt messages. But here’s the catch: that key never travels through a secure channel. It passes through the open internet — routers, servers, ISPs — all of which are visible to anyone who wants to snoop.

So the obvious question is:

How can two devices agree on a secret key without ever sending it directly over the network?

The answer lies in one of the most elegant pieces of cryptography ever invented — the Diffie–Hellman Key Exchange.

🧩 The Core Idea

Let’s imagine two people — Vipul and Meera — who want to talk securely.

They can communicate over a public channel, which everyone (including a hacker named Suresh) can listen to.

Their goal is to somehow create a shared secret that only they know, without ever sending the secret itself.

Here’s where Diffie–Hellman shines. It lets Vipul and Meera each choose private secrets, share some public information, and still end up with the same shared key — one that even Suresh can’t figure out, despite seeing all their messages.

⚙️ How It Works (Step-by-Step)

Let’s break it down in simple terms.

=> 1. Agree on public numbers:

Vipul and Meera start by agreeing on two public numbers:

A large prime number p
A base (also called a generator) g

These two values can be known to everyone — even Suresh can see them.

=> 2. Each picks a private secret:

Vipul chooses a secret number a (kept private).
Meera chooses a secret number b (kept private).

=> 3. They create their public keys:

Vipul computes A = g^a mod p
Meera computes B = g^b mod p

Then they exchange these public keys A and B openly.

=> 4. They compute the shared secret:

Vipul computes S = B^a mod p
Meera computes S = A^b mod p

Both get the same shared secret S.

Even though Suresh knows g, p, A, and B, he can’t easily find a or b — because that would mean solving the discrete logarithm problem, which is practically impossible for large numbers.

🔒 Why It’s Secure

The security of Diffie–Hellman lies in the fact that it’s easy to compute g^a mod p, but extremely hard to reverse it — that is, to find a from g^a mod p.

This makes it possible for Vipul and Meera to exchange some public data and still end up with a secret that no one else can reconstruct.

🌍 Real-World Uses

Diffie–Hellman isn’t just theory — it’s used everywhere around us:

HTTPS (TLS/SSL): When you see the lock icon in your browser, your device has likely used Diffie–Hellman (or a variant) to set up a secure connection.
Messaging apps: Protocols like Signal’s Double Ratchet Algorithm build upon Diffie–Hellman to keep your chats safe.
VPNs: Secure tunnels between your device and a server often rely on DH or its modern form, ECDH (Elliptic-Curve Diffie–Hellman).

🧠 A Modern Twist: Elliptic-Curve Diffie–Hellman (ECDH)

Traditional Diffie–Hellman uses large prime numbers, which can be computationally heavy.

ECDH replaces those with points on an elliptic curve, achieving the same level of security with much smaller keys — faster and more efficient.

That’s why ECDH is now used in HTTPS, SSH, and secure messaging apps like Signal and WhatsApp.

🪄 The Takeaway

The beauty of the Diffie–Hellman Key Exchange is that it lets two people — like Vipul and Meera — create a shared secret key without ever sending it directly.

It’s pure mathematical magic that forms the foundation of the encryption we rely on every day.

So the next time an app says “end-to-end encrypted”, you’ll know what’s happening behind the scenes:

a quiet, invisible handshake powered by math — where public numbers meet private secrets to build unbreakable trust. 🔐

Browser Storage Explained: LocalStorage vs SessionStorage vs IndexedDB vs Cookies

Arnav Sharma — Mon, 01 Sep 2025 09:19:03 +0000

When building modern web applications, storing data in the browser is essential for improving user experience, reducing server load, and enabling offline capabilities. But with multiple storage options available—LocalStorage, SessionStorage, IndexedDB, and Cookies—it’s easy to get confused about which one to use and when.

Let’s break them down with a clear comparison.

🌐 1. LocalStorage

What it is

LocalStorage is a simple key–value storage mechanism provided by the browser. Data is stored persistently, meaning it remains even after the browser is closed and reopened.

Key features

Capacity: ~5–10 MB (depends on browser).
Data persists until explicitly cleared (by code or user).
Synchronous API (may block the main thread if used heavily).
Stores string data only (objects must be stringified).

Use cases

Saving user preferences (theme, layout).
Caching small API responses.
Storing lightweight app state (e.g., last visited tab).

✅ Best for: Simple, persistent key-value storage.

🕒 2. SessionStorage

What it is

SessionStorage works similarly to LocalStorage but is tied to the browser session. Data is cleared when the tab is closed.

Key features

Capacity: ~5 MB.
Data is isolated per tab/window (even the same site in a new tab won’t share it).
Synchronous API.
Stores string data only.

Use cases

Temporary form data.
Preventing multiple submissions.
Data needed only while the page is open.

✅ Best for: Short-lived data specific to a single tab.

📦 3. IndexedDB

What it is

IndexedDB is a low-level, NoSQL database built into browsers. It allows storing large amounts of structured data, including files/blobs.

Key features

Capacity: Hundreds of MBs to GBs (depends on browser & user storage limits).
Data persists until cleared.
Asynchronous API (non-blocking).
Can store objects, arrays, blobs, and more.
Supports transactions, indexes, and queries.

Use cases

Offline-first applications (e.g., note-taking apps, todo apps).
Large datasets (caching JSON, images, or videos).
Complex querying and searching inside the browser.

✅ Best for: Storing large or structured data.

🍪 4. Cookies

What they are

Cookies are the oldest form of browser storage, designed primarily for server–client communication. They can store small pieces of data and are sent with every HTTP request to the server.

Key features

Capacity: ~4 KB per cookie.
Can be set to expire or persist.
Sent to the server with each request (can affect performance).
Accessible by both client-side JavaScript and the server (if not marked HttpOnly).
Can be secured with flags like Secure, HttpOnly, SameSite.

Use cases

Authentication tokens (though JWT/localStorage is now more common).
Remembering logged-in sessions.
Tracking (though privacy regulations limit this now).

✅ Best for: Server–client communication and small, secure data.

⚖️ Comparison Table

Feature	Local Storage	Session Storage	IndexedDB	Cookies
Storage limit	~5–10 MB	~5 MB	Hundreds MBs–GBs	~4 KB per cookie
Persistence	Until cleared	Until tab closes	Until cleared	Configurable expiry
Data type	Strings only	Strings only	Structured (objects, blobs)	Strings only
Accessibility	JS only	JS only	JS only	JS + Server
Sent to server	❌ No	❌ No	❌ No	✅ Yes
Best for	Preferences, cache	Tab-specific data	Large/complex offline data	Auth, sessions

🚀 Final Thoughts

Browser storage is not “one size fits all.” Each option is designed for different use cases: LocalStorage and SessionStorage are great for small, simple data; IndexedDB is the powerhouse for complex offline apps; and Cookies are still essential for server communication.

👉 The right choice depends on your app’s data size, persistence needs, and whether the server requires access.

What Happens When You Type a URL in the Browser?

Arnav Sharma — Wed, 27 Aug 2025 13:03:59 +0000

Have you ever wondered what really happens when you type www.google.com into your browser and hit Enter?

It feels instant — but under the hood, your browser, operating system, and the internet work together through a fascinating sequence of steps. Let’s break it down step by step.

1. You Enter the URL

When you type a URL (Uniform Resource Locator) like https://example.com, the browser starts interpreting it:

Protocol: https:// tells the browser how to communicate (secure HTTP here).
Domain Name: example.com needs to be translated into an IP address.
Path & Query: /products?id=123 tells the server which resource you want.

2. Browser Checks Cache

Before making any request, the browser looks for shortcuts:

Browser cache → Has this site been visited before?
Operating System cache → Stored DNS lookups.
Router cache → Local network remembers common addresses.
ISP cache → Your internet provider may store DNS results.

If the IP address for the domain is already cached, the browser skips DNS lookup. Otherwise…

3. DNS Resolution (Domain → IP)

Your browser needs to know the actual server address (like 142.250.182.14 for Google). This is where DNS (Domain Name System) comes in:

Ask the local DNS resolver (usually at your ISP).
If not found, it queries the Root DNS servers.
Then moves to the Top-Level Domain (TLD) servers (like .com).
Finally, it reaches the Authoritative DNS server that knows the exact IP of example.com.

Result: The domain name is translated into an IP address.

4. Browser Establishes a Connection (TCP Handshake)

Now that we have the IP, the browser establishes a connection using TCP (Transmission Control Protocol):

SYN: Browser says hello.
SYN-ACK: Server replies hello.
ACK: Browser confirms.

This is called the 3-way handshake. It ensures both browser and server are ready to communicate.

5. Secure Connection (TLS Handshake for HTTPS)

Since most sites use HTTPS, another step kicks in:

Browser and server agree on encryption protocols.
They exchange certificates to verify trust (via Certificate Authorities).
A secure encrypted channel is created.

This ensures data you send/receive is private.

6. Browser Sends HTTP Request

Finally, the browser sends a request, for example:

GET / HTTP/1.1
Host: example.com
User-Agent: Chrome/120.0
Accept: text/html

This tells the server: “Hey, I want the homepage of example.com.”

7. Server Processes the Request

On the server side:

The request reaches the web server software (like Nginx, Apache, Node.js).
The server may fetch data from databases, run application logic, or return a static file.
The server responds with an HTTP response, e.g.:

HTTP/1.1 200 OK
Content-Type: text/html

…followed by the HTML of the page.

8. Browser Receives the Response

The browser now gets the raw HTML. But it’s just the beginning:

Parse HTML → Build the DOM (Document Object Model).
Parse CSS → Build the CSSOM (CSS Object Model).
Run JavaScript → Modify DOM/CSSOM.
Construct Render Tree → Combine DOM + CSSOM.
Layout & Paint → Calculate positions and paint pixels on screen.

9. Loading Extra Resources

The HTML often contains references to:

CSS files
JavaScript files
Images, fonts, videos

Each of these triggers more HTTP requests, which go through similar DNS + TCP + TLS steps (unless cached).

10. You See the Page

At last, all resources are downloaded, parsed, and rendered. The page becomes interactive as JavaScript finishes execution.

From typing a URL to seeing a fully loaded website, this entire process usually happens in milliseconds.

⚡ TL;DR (Quick Recap)

When you type a URL:

Browser checks cache
DNS resolves domain → IP
TCP handshake
TLS handshake (HTTPS)
Browser sends HTTP request
Server processes request
Browser receives response
Browser parses + renders page
Additional resources load
Page displayed to you

🌐 Why Should You Care?

Understanding this flow helps developers:

Debug performance bottlenecks
Improve website loading speed
Secure web apps with HTTPS
Appreciate the hidden complexity behind a “simple” click

👉 Next time you hit Enter in your browser, remember: an entire orchestra of systems plays in perfect sync to deliver that page in the blink of an eye.

A/B Testing 101: A Beginner’s Guide to Smarter Decisions

Arnav Sharma — Tue, 26 Aug 2025 01:32:58 +0000

“Without data, you’re just another person with an opinion.”

— W. Edwards Deming

Whether you’re launching a new feature, redesigning your app, or tweaking a call-to-action button, product decisions can feel like a gamble. What if users don’t like it? What if conversions drop?

This is where A/B testing comes to the rescue. It’s one of the simplest yet most powerful tools for making data-backed decisions instead of relying on guesswork.

What is A/B Testing?

At its core, A/B testing is an experiment.

You take two (or more) versions of something, show them to different user groups at the same time, and measure which one performs better.

Example: Testing the color of a “Sign Up” button.

Version A → Green button
Version B → Blue button
Version C → Red button

If Version B consistently drives more signups, you’ve found your winner.

👉 It’s not about opinions — it’s about evidence.

Why A/B Testing Matters

A/B testing is more than button colors. It helps teams:

✅ Make Data-Driven Decisions → Replace gut feelings with evidence.

✅ Reduce Risk → Test small changes before rolling out big ones.

✅ Optimize Key Metrics → Conversions, engagement, revenue — all measurable.

✅ Create a Learning Culture → Every test teaches you about your users.

✅ Scale Confidently → With proof that changes work, scaling becomes safer.

💡 Fun fact: Companies like Google, Amazon, and Netflix run thousands of A/B tests every year to optimize everything from recommendations to pricing.

How Does A/B Testing Work?

Running an A/B test typically involves three major steps:

Define Success Metrics

What are you measuring? Click-through rate? Time on page? Purchases?
Split Your Traffic Randomly

Half your users see Version A, the other half see Version B. (Some tests include multiple variants — A/B/C, etc.)
Analyze Results

Use statistical methods (like confidence intervals or p-values) to check if the difference is real and not just random.

👉 Pro tip: Don’t end tests too early — trends can flip as more data comes in.

Components of a Strong A/B Test

For an effective test, you need:

Hypothesis → A clear statement of what you expect.

Example: “Changing the button color from green to blue will increase clicks by 10%.”
Variants → Different versions you’re testing.
Sample Size → Enough users to make the test statistically valid.
Metrics → Clearly defined KPIs (e.g., sign-ups, purchases, bounce rate).
Control vs Experiment → One version stays the same (control), the other changes (experiment).

⚠️ Warning: If your sample size is too small, your results will be unreliable — like flipping a coin only twice.

Common Pitfalls in A/B Testing

Even well-meaning teams can fall into traps:

❌ Testing the Wrong Things → Not every detail needs testing (don’t waste time on logo size).

❌ Stopping Tests Too Soon → Early results often flip after more data.

❌ Chasing Vanity Metrics → More clicks don’t always mean more conversions.

❌ Small Sample Sizes → Leads to misleading results.

❌ Ignoring Qualitative Data → Numbers tell what happened, but not why.

Best Practices for A/B Testing

If you want reliable, actionable insights:

Start with a Clear Hypothesis → Know what you’re testing and why.
Focus on One Variable at a Time → Changing too many things makes it impossible to know what worked.
Run Tests Long Enough → Capture weekdays, weekends, and normal usage patterns.
Segment Your Audience → A change might work for new users but not for returning ones.
Always Document Results → Even failed experiments teach you something.

Beyond A/B: Advanced Testing

Once you’re comfortable, you can go further:

Multivariate Testing (MVT) → Test multiple elements at once (e.g., button color + headline).
Multi-Armed Bandit → Automatically shifts more traffic to winning variants as results come in.
Personalization Experiments → Different users see different versions based on behavior, not random splits.

Real-World Examples

Booking.com → Runs over 1,000 concurrent tests at any time to tweak pricing, messaging, and UX.
Amazon → Tests everything from product recommendations to checkout flows.
Netflix → A/B tested thumbnails, trailers, and UI layouts to increase watch time.

If the giants are doing it, there’s a reason: it works.

Key Takeaways

A/B testing is not just about “what button color works best.” It’s about:

Building a culture of learning.
Reducing risk through evidence.
Continuously improving your product with real user data.

Remember the mantra:

👉 Test → Measure → Learn → Repeat

Do this consistently, and you’ll turn product decisions from guesswork into science.

Understanding CORS: Why Your API Request Failed

Arnav Sharma — Sat, 23 Aug 2025 16:18:34 +0000

If you’ve built a frontend that talks to an API, chances are you’ve seen this error in your console:

Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' 
has been blocked by CORS policy.

At first glance, it feels random. Your API is up, your code looks fine… so why does the browser stop you?

The answer is CORS (Cross-Origin Resource Sharing) — one of those things that sounds complicated, but once you “get it,” debugging becomes way easier.

Let’s break it down step by step.

What is CORS, really?

CORS is a security feature in browsers. It basically says:

“A website should not be able to make requests to another site unless the other site explicitly says it’s okay.”

Example:

Your frontend runs at http://localhost:3000
Your backend API is at https://api.example.com

These are different origins (different host/port/protocol), so the browser treats the request as cross-origin.

And here’s the key: without CORS, any malicious website could secretly call APIs on your behalf (like your bank), and steal data.

So when your browser blocks that request, it’s not being mean — it’s protecting you.

How does CORS actually work?

Here’s the flow whenever you hit an API from another origin:

The Browser Adds an Origin Header Example:

   Origin: http://localhost:3000

The Server Decides if It’s Allowed It must respond with something like:

   Access-Control-Allow-Origin: http://localhost:3000

If it matches, the browser lets the request go through. If not → CORS error.

Preflight Requests (the “double request” thing you see) For some requests (PUT, DELETE, custom headers, etc.), the browser first sends an OPTIONS request (aka preflight). The server must reply with allowed methods and headers:

   Access-Control-Allow-Methods: GET, POST, PUT  
   Access-Control-Allow-Headers: Content-Type, Authorization

If anything’s missing, your actual request never gets sent.

Why your request failed (common reasons)

No CORS headers at all
→ The server just didn’t set them.
Wrong origin allowed
→ You’re on http://localhost:3000, but the server only allows https://myapp.com.
Preflight not handled
→ The server ignores the OPTIONS request, so the browser stops right there.
Credentials issue
→ You’re sending cookies/tokens, but the server didn’t set

   Access-Control-Allow-Credentials: true

How to fix CORS issues

1. Set CORS headers on the server

In Node.js + Express:

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "http://localhost:3000");
  res.header("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
  res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");
  next();
});

(Pro tip: just use the cors package, it saves you headaches.)

2. Use `*` in dev (but not in prod)

Access-Control-Allow-Origin: *

Great for local testing. Terrible for production. Never expose private APIs this way.

3. Enable credentials if needed

res.header("Access-Control-Allow-Credentials", "true");

And in frontend:

fetch(url, { credentials: "include" });

4. Use a proxy during development

If you can’t change the backend (e.g., third-party APIs), use a proxy (Vite/CRA/Webpack dev server) so the request looks like it comes from the same origin.

Best Practices

Whitelist only the domains you trust.
Always handle OPTIONS requests properly.
Remember: CORS exists to protect users, not annoy developers (even though it feels that way sometimes).

Wrapping up

CORS errors are annoying, but they’re also a sign your browser is doing its job.

The trick is to remember:

The server decides who can call it.
The browser enforces that rule.

So next time you see the dreaded “blocked by CORS policy”, don’t panic. Check the headers, check the origin, and you’ll know exactly what’s wrong.

How SQL Queries Really Work: From Parsing to Execution

Arnav Sharma — Sat, 23 Aug 2025 10:32:51 +0000

Ever wondered what happens after you hit run on a SQL query? Here’s a clear journey from parsing to execution.

Introduction

If you’ve ever written a SQL query and hit run, you might assume the database just reads it top-to-bottom and executes it line by line. But under the hood, something much more sophisticated happens.

Every SQL query goes through a three-step journey before you see results:

Parse → Optimize → Execute

Understanding this process not only deepens your knowledge of databases but also helps you write faster queries, debug performance issues, and make the most of indexes and query planners.

1. Query Parsing

What Happens During Parsing?

When you send a SQL query to the database, the first thing it does is parse it. Parsing ensures your query is valid and can be understood by the database engine.

Syntax Check:

The database checks if your SQL follows proper syntax. If you miss a semicolon or misuse a keyword, parsing fails immediately.
Validation Against Schema:

The query is checked against the database schema. For example, does the table users exist? Does the column age belong to it?

Parse Tree Generation

If everything checks out, the query is transformed into a parse tree — a structured representation of the query. Instead of being just text, it becomes a hierarchical tree that the database can work with.

Think of this as turning your SQL into a machine-readable structure.

2. Query Optimization

Once parsed, the query moves to the optimizer — the brain of the database.

Logical Optimization

The optimizer rewrites the query to simplify it without changing its meaning. Examples:

Removing unnecessary filters
Reordering operations for efficiency
Simplifying expressions (WHERE age > 18 AND age > 10 → WHERE age > 18)

Cost-Based Optimization

Here’s where the database really shines. The optimizer estimates the cost of different ways to execute your query — measuring factors like disk I/O, CPU usage, and memory.

It then chooses the most efficient strategy, considering:

Indexes: Should it scan sequentially or use an index?
Join Orders: Should users be joined with orders first, or the other way around?
Access Paths: Which path to data retrieval is fastest?

Execution Plan Creation

The optimizer produces an execution plan — a detailed blueprint of how the query will run.

Developers can peek into this with commands like:

EXPLAIN SELECT * FROM users WHERE age > 30;

The plan shows whether the database will do an index scan, sequential scan, or some other strategy.

3. Query Execution

Now the plan is handed off to the execution engine, which actually retrieves the data.

Execution Engine Role

The engine takes the execution plan and performs step-by-step operations.

Key Steps in Execution

Table Scans:

-   _Sequential Scan_: Reads the entire table row by row.

-   _Index Scan_: Uses an index to quickly jump to matching rows.

Applying Filters and Projections:

Apply the WHERE condition (age > 30) and select only the requested columns.
Joins and Aggregations:

If your query has joins or aggregates (SUM, COUNT, GROUP BY), these are computed at this stage.
Returning Results to the Client:

Results are streamed back row by row, not all at once, which allows large result sets to be handled efficiently.

4. Real-World Example

Let’s walk through a simple query:

SELECT * FROM users WHERE age > 30;

Parsing:

The query is checked for valid syntax, confirms that the users table exists, and that the age column is valid.
Optimization:

The optimizer considers:
- Sequential scan (read all rows, filter age > 30)
- Index scan (if an index exists on age, jump directly to rows > 30) It picks the cheaper one.
Execution:

The chosen plan runs. Rows with age > 30 are fetched, filtered, and returned to the client.

Perfect — let’s expand Section 5 with the actual execution order of SQL queries, which is very different from the way we write them. Here’s the revised section with a clear step-by-step execution flow:

5. Common Misconceptions About SQL Execution

“SQL just runs top to bottom” → Wrong.

SQL is declarative: you describe what you want, not how to get it. The optimizer and execution engine decide the how.

Logical Order vs Execution Order

When you write a query, it looks like this:

SELECT column_list
FROM table
WHERE condition
GROUP BY grouping_column
HAVING group_condition
ORDER BY column_list
LIMIT n;

But internally, the database executes it in a different order:

Actual Execution Order

FROM – Identify the source tables.
JOIN / ON – Combine tables based on join conditions.
WHERE – Filter rows before grouping.
GROUP BY – Group rows into buckets.
HAVING – Filter groups.
SELECT – Choose which columns/expressions to return.
DISTINCT – Remove duplicates if requested.
ORDER BY – Sort the results.
LIMIT / OFFSET – Return only a subset of rows.

👉 Example:

SELECT name, COUNT(*)
FROM users
WHERE age > 30
GROUP BY name
HAVING COUNT(*) > 2
ORDER BY name ASC
LIMIT 5;

Rows are pulled from users (FROM).
Filtered to only those with age > 30 (WHERE).
Grouped by name (GROUP BY).
Groups with fewer than 2 rows are removed (HAVING).
Final columns are selected (SELECT).
Results sorted by name (ORDER BY).
Top 5 returned (LIMIT).

This is why sometimes putting a condition in WHERE vs HAVING makes a big difference — because row filters happen before grouping, while group filters happen after grouping.

6. Why This Knowledge Helps Developers

Write Efficient Queries:

Knowing how queries are parsed and optimized helps you design queries the optimizer can handle well.
Debug Performance Issues:

Slow query? Run EXPLAIN to see if the optimizer picked a bad plan.
Understand Indexes and Execution Plans:

Indexes don’t always help. Understanding execution flow helps you decide when to add (or avoid) them.

Conclusion

SQL queries don’t just run. They go through a journey:

Parse → Optimize → Execute

Next time you run a query, remember that your database is doing a lot of behind-the-scenes work to give you results efficiently.

👉 Pro tip: Use EXPLAIN to peek into your database’s brain and learn how your queries really run.

Pub/Sub Architecture: Push vs Pull Messaging (When to Use Each)

Arnav Sharma — Thu, 21 Aug 2025 06:08:12 +0000

What is Pub/Sub?

Publish/Subscribe (pub/sub) is a messaging pattern where publishers send messages without knowing who will consume them, and subscribers receive messages without knowing who produced them.

A broker (like Kafka, RabbitMQ, SQS, Redis) usually sits in the middle to handle message delivery.

This decoupling allows systems to communicate asynchronously and scale independently.

Why Pub/Sub?

Pub/Sub solves several common problems in distributed systems:

Decoupling – Publishers don’t need to know subscribers.
Scalability – Multiple subscribers can process messages independently.
Reliability – Messages are queued until consumed (depending on broker).
Flexibility – One message can be delivered to many subscribers (fanout).

When Pub/Sub?

Use pub/sub when:

You want event-driven architecture (e.g., user signup triggers emails, notifications).
You need to scale workers dynamically.
You need loose coupling between microservices.
You need to ensure asynchronous processing (background jobs, pipelines).

Don’t use pub/sub when you need strict request/response (synchronous API calls).

How Pub/Sub (Types)

There are two main ways subscribers receive messages:

🔹 Push-based Pub/Sub

The broker pushes messages directly to subscribers.
Subscribers don’t need to poll.
Example: RabbitMQ pushes messages to consumers.

✅ Low latency

✅ Easy subscriber logic

❌ Risk of overwhelming slow subscribers

🔹 Pull-based Pub/Sub

Subscribers request (pull) messages from the broker when ready.
Example: AWS SQS requires consumers to poll for messages.

✅ Subscribers control pace (backpressure handling)

✅ Reliable retries

❌ Slightly higher latency due to polling

Comparison

Feature	Push-based Pub/Sub	Pull-based Pub/Sub
Delivery model	Broker delivers	Subscriber requests
Latency	Lower (instant delivery)	Higher (polling delay)
Backpressure control	Harder	Easier
Subscriber logic	Simple (just receive)	More complex (polling)
Example tech	RabbitMQ, Redis Pub/Sub	AWS SQS, Kafka

Which Tech Uses Which One and How?

🐇 RabbitMQ (Push-based)

Consumers register with a queue.
RabbitMQ pushes messages to consumers.
You can configure prefetch to avoid overloading consumers.
Great for real-time apps (chat, IoT, financial trading).

☁️ AWS SQS (Pull-based)

Messages are stored in SQS queues.
Consumers must poll SQS to fetch them.
Can use long polling for efficiency.
Great for cloud pipelines, serverless apps, microservices decoupling.

Real World Example

Imagine an e-commerce platform:

A customer places an order.
Publisher: Order service emits an order_created event.
Push-based: A notification service instantly gets the event via RabbitMQ and sends an SMS.
Pull-based: A reporting service pulls events from SQS at its own pace to update sales dashboards.

Conclusion

Both pull-based and push-based pub/sub models have their strengths:

Push-based is best when you need low latency, real-time delivery (RabbitMQ, Redis Pub/Sub).
Pull-based is best when you need scalability, reliability, and backpressure control (AWS SQS, Kafka).

👉 The right choice depends on your use case:

For real-time notifications, go with push.
For background processing or analytics, go with pull.

In modern architectures, teams often combine both models—push for immediate actions, pull for batch or heavy workloads.

Views in PostgreSQL: A Complete Guide with Examples

Arnav Sharma — Sun, 17 Aug 2025 14:51:18 +0000

When working with relational databases like PostgreSQL, you often need to simplify complex queries, enforce data security, or speed up reporting. That’s where Views come in.

A view is essentially a virtual table defined by a query. Instead of writing the same complex query again and again, you save it as a view and query it like a table.

In this blog, we’ll explore the different types of views in PostgreSQL, their use cases, pros and cons, examples, and best practices.

🏷️ Types of Views in PostgreSQL

1. Simple View

📌 What is it?

A view built from a single table without joins or aggregations.

✅ Why use it?

Hide unnecessary columns
Simplify queries
Enforce limited access

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name TEXT,
    department TEXT,
    salary NUMERIC,
    active BOOLEAN
);

-- Simple view showing only basic employee info
CREATE VIEW employee_public_info AS
SELECT id, name, department
FROM employees;

SELECT * FROM employee_public_info;

⚖️ Pros: Lightweight, updatable, always real-time

⚖️ Cons: Doesn’t reduce computation cost

2. Complex View

📌 What is it?

A view involving joins, group by, or aggregates.

✅ Why use it?

Simplify reporting queries
Centralize business logic

CREATE TABLE sales (
    id SERIAL PRIMARY KEY,
    employee_id INT,
    amount NUMERIC,
    sale_date DATE
);

-- Complex view: total sales per department
CREATE VIEW department_sales AS
SELECT e.department, SUM(s.amount) AS total_sales
FROM employees e
JOIN sales s ON e.id = s.employee_id
GROUP BY e.department;

SELECT * FROM department_sales;

⚖️ Pros: Great for dashboards, reduces repeated SQL code

⚖️ Cons: Usually not updatable, may be slow on large datasets

3. Materialized View

📌 What is it?

A pre-computed, stored result set of a query. Unlike normal views, it stores data on disk.

✅ Why use it?

Speed up expensive queries
Power analytics dashboards

CREATE MATERIALIZED VIEW monthly_sales AS
SELECT DATE_TRUNC('month', sale_date) AS month,
       SUM(amount) AS total
FROM sales
GROUP BY DATE_TRUNC('month', sale_date);

-- Refresh when new data arrives
REFRESH MATERIALIZED VIEW monthly_sales;

SELECT * FROM monthly_sales ORDER BY month;

⚖️ Pros: Huge performance boost, can be indexed

⚖️ Cons: Data can get stale, needs manual refresh

4. Updatable View

📌 What is it?

A view where you can INSERT, UPDATE, DELETE rows directly.

✅ Why use it?

Provide restricted updates without exposing full table

-- Only active employees
CREATE VIEW active_employees AS
SELECT *
FROM employees
WHERE active = true;

-- Update via the view
UPDATE active_employees SET active = false WHERE id = 3;

⚖️ Pros: Secure way to allow controlled updates

⚖️ Cons: Works only with simple queries

5. Read-Only View

📌 What is it?

A view that cannot be updated (complex logic, joins, or aggregates).

✅ Why use it?

Safely expose analytics reports

-- Employees with high sales
CREATE VIEW top_performers AS
SELECT employee_id, SUM(amount) AS total_sales
FROM sales
GROUP BY employee_id
HAVING SUM(amount) > 50000;

SELECT * FROM top_performers;

⚖️ Pros: Safe for reporting

⚖️ Cons: Can’t modify data through it

6. Recursive View

📌 What is it?

A view built using a recursive CTE to handle hierarchies.

✅ Why use it?

Org charts, folder structures, category trees

-- Hierarchy of employees and managers
CREATE VIEW employee_hierarchy AS
WITH RECURSIVE emp_cte AS (
    SELECT id, name, manager_id
    FROM employees
    WHERE manager_id IS NULL
    UNION ALL
    SELECT e.id, e.name, e.manager_id
    FROM employees e
    JOIN emp_cte c ON e.manager_id = c.id
)
SELECT * FROM emp_cte;

SELECT * FROM employee_hierarchy;

⚖️ Pros: Perfect for recursive data

⚖️ Cons: Can get slow for deep hierarchies

🛒 Real-World Example: Views in an E-commerce App

Imagine you’re building an e-commerce platform. Here’s how different views fit in:

Simple View → customer_directory (hide sensitive columns)
Complex View → category_revenue (total revenue per category)
Materialized View → daily_sales (fast dashboards with precomputed data)
Updatable View → active_products (only allow editing active products)
Read-Only View → top_customers (find VIPs safely)
Recursive View → category_hierarchy (nested categories navigation)

By mixing these types, your database becomes secure, performant, and easy to query.

⚡ Performance Best Practices

Index Materialized Views

CREATE UNIQUE INDEX idx_daily_sales_date ON daily_sales(order_date);

Refresh Strategy

-   Refresh materialized views with `REFRESH MATERIALIZED VIEW` at scheduled times (e.g., nightly with `pg_cron`).

Optimize Complex Views

-   Break into smaller views or switch to materialized views if performance is bad.

Use WITH CHECK OPTION for updatable views

CREATE VIEW active_products AS
SELECT * FROM products WHERE is_active = true
WITH CHECK OPTION;

Recursive Views: Add Depth Limit
```
WHERE p.depth < 10;
```

🏆 Key Takeaways

Use simple & complex views for query simplification and security.
Use materialized views for performance-heavy reporting.
Use updatable views with care.
Use recursive views for hierarchical data.
Always balance freshness vs performance.

With the right type of view, you can make your PostgreSQL database faster, safer, and easier to work with 🚀

Protobuf vs JSON Explained: Speed, Size & When to Use Each

Arnav Sharma — Sun, 27 Jul 2025 20:20:18 +0000

Modern applications thrive on fast and efficient communication. While JSON has long been the go-to format for data exchange, many large-scale tech companies are now rethinking their choice. One such example is Atlassian, which made a strategic shift from JSON to Protocol Buffers (Protobuf) to optimize performance and reduce payload sizes across services.

Their motivation? Faster API responses, smaller data transfers, and better compatibility for growing systems.

In this blog, we’ll break down what JSON and Protobuf are, compare their strengths and weaknesses, and walk you through how to use Protobuf in a Node.js project. If you're wondering whether it's time for your project to evolve beyond JSON, this guide is for you.

1. What is JSON?

JSON (JavaScript Object Notation) is a lightweight, human-readable data format commonly used in web APIs and configs. It's based on JavaScript syntax and supported by virtually all programming languages.

Example:

{
  "name": "Alice",
  "age": 28,
  "isActive": true
}

2. Why is JSON Preferred?

JSON is often the go-to format because:

✅ Readable: Easily understood and edited by humans.
✅ Simple: No need for extra libraries in JavaScript/Node.js.
✅ Interoperable: Works across all platforms and languages.
✅ Debug-friendly: Can be logged and inspected directly.

But JSON has limitations in performance, file size, and type safety, especially in large systems.

3. About Protobuf

Protocol Buffers (Protobuf) is a binary serialization format developed by Google. It encodes data into compact, fast, and structured bytes using .proto definitions.

Key features:

🚀 Compact binary format
⚡ Faster parsing and serialization than JSON
✅ Schema enforcement via .proto files
🔁 Backward and forward compatibility support

Example .proto file:

syntax = "proto3";

message User {
  string name = 1;
  int32 age = 2;
  bool is_active = 3;
}

4. Protobuf vs JSON: Key Differences

Feature	JSON	Protobuf
Format	Text (UTF-8)	Binary
Readable	Yes	No
Size	Larger	Smaller
Speed	Slower	Faster
Schema	Optional	Required (`.proto`)
Type Safety	Weak	Strong
Versioning	Manual	Built-in support

5. How to Use Protobuf in Node.js

We’ll use protobufjs, a popular library for Protobuf support in Node.js.

🔧 Step 1: Install the Package

npm install protobufjs

📝 Step 2: Create a `.proto` File

Save this as user.proto:

syntax = "proto3";

message User {
  string name = 1;
  int32 age = 2;
  bool is_active = 3;
}

⚙️ Step 3: Load and Use in Node.js

const protobuf = require("protobufjs");

async function main() {
  const root = await protobuf.load("user.proto");
  const User = root.lookupType("User");

  // Create a new user object
  const payload = { name: "Alice", age: 28, is_active: true };

  // Verify the payload
  const errMsg = User.verify(payload);
  if (errMsg) throw Error(errMsg);

  // Encode the payload to a buffer
  const message = User.create(payload);
  const buffer = User.encode(message).finish();
  console.log("Encoded buffer:", buffer);

  // Decode the buffer back to an object
  const decoded = User.decode(buffer);
  console.log("Decoded object:", decoded);
}

main();

🧪 Output

Encoded buffer: <Buffer 0a 05 41 6c 69 63 65 10 1c 18 01>
Decoded object: { name: 'Alice', age: 28, isActive: true }

6. When to Use Protobuf

✅ Use Protobuf when:

You’re building microservices or using gRPC
Performance and bandwidth are critical
Data payloads are large or frequent
You need strict schemas and versioning

✅ Use JSON when:

You want human-readable data
Working with REST APIs or frontend-heavy apps
You need quick debugging and prototyping

🧾 Conclusion

Use Case	Recommendation
Human readability	JSON
Performance	Protobuf
Browser apps	JSON
Microservices	Protobuf
Debugging	JSON
Schema evolution	Protobuf

Both formats have their place. JSON is perfect for human-facing interfaces and simple APIs, while Protobuf excels in high-performance and structured systems.

💡 Tip: If you're using gRPC or building APIs for scale, start with Protobuf.

Got questions about implementing Protobuf in your Node.js backend? Drop them in the comments or reach out on GitHub!

How Indexes Work in Databases: Deep Dive into MongoDB & PostgreSQL

Arnav Sharma — Fri, 18 Jul 2025 05:23:09 +0000

I’ve been working with databases like MongoDB and PostgreSQL for quite a while now. One thing I’ve used frequently—sometimes almost instinctively—is indexing. Whether it was speeding up queries, optimizing reads, or designing complex filters, indexes always played a role. But recently, I felt the need to dive deeper and understand how indexing is actually implemented, what features it offers beyond performance, and how different databases approach it.

Let’s explore indexing from scratch, how it works in MongoDB and PostgreSQL, and some best practices I’ve learned along the way.

🔍 What is Indexing?

Indexing is like the table of contents in a book. Instead of scanning every single page (or row), you can jump directly to what you need. Technically, an index is a data structure that allows the database to locate data faster, typically implemented using variations of B-trees, hash maps, or other specialized structures.

Think of it as a roadmap for the database engine to retrieve data efficiently.

🚀 Why Indexing?

Without indexing:

Queries perform full table scans, slowing down performance.
Complex filters, sorting, and joins become resource-intensive.
Scalability is limited as datasets grow.

With indexing:

You get faster query execution (especially on large datasets).
Sorting and filtering become efficient.
It improves read-heavy workloads significantly.

In short: indexing is the backbone of performance optimization in databases.

📦 Indexing in MongoDB

MongoDB, being a document-oriented NoSQL database, has its own flavor of indexing:

Single Field Index:
```
db.users.createIndex({ name: 1 });
```

Compound Index (multiple fields):

db.orders.createIndex({ customerId: 1, createdAt: -1 });

Text Index: For full-text search.

db.articles.createIndex({ content: "text" });

Geospatial Index: Useful for "nearby" queries (e.g., delivery apps).
```
db.places.createIndex({ location: "2dsphere" });
```
Multikey Index: Automatically created for array fields.
Hashed Index: Mainly used for sharding.
Wildcard Index: Indexes unknown/nested fields without schema knowledge.

MongoDB indexes are flexible and schema-less, which makes them ideal for fast-changing document structures.

🛠️ Indexing in PostgreSQL

PostgreSQL offers one of the most robust and versatile indexing systems among relational databases.

B-tree Index (default): Great for equality and range queries.
```
CREATE INDEX idx_name ON users(name);
```

GIN Index: For full-text search, arrays, JSONB.

CREATE INDEX idx_gin ON posts USING gin(tags);

Expression Index:

CREATE INDEX idx_lower_email ON users(LOWER(email));

Partial Index:

CREATE INDEX idx_active_users ON users(email) WHERE active = true;

Hash Index: Only for equality (=) comparisons.
GiST Index: For geospatial, full-text, and fuzzy search.
BRIN Index: For huge tables where data is stored sequentially (e.g., logs).
Covering Index (INCLUDE clause): Useful when you want to avoid accessing the actual table.

Postgres indexing is extremely powerful when it comes to structured data, analytics, and optimization.

🆚 MongoDB vs PostgreSQL Indexing

Feature	MongoDB	PostgreSQL
Default Index Type	B-tree	B-tree
Full-Text Search	`text` index (basic)	`GIN` + `tsvector` (advanced)
Geospatial Support	2d/2dsphere	GiST, PostGIS (more powerful)
Multikey Index	Yes (array support)	Limited (not auto-handled)
Partial Index	Yes	Yes
Expression Index	No	Yes
Covering Index	No	Yes (with `INCLUDE`)
Wildcard Index	Yes	No

Specialties:

MongoDB shines with array fields and dynamic schemas, thanks to multikey and wildcard indexes.
PostgreSQL excels in complex querying, full-text search, and advanced filtering, thanks to its expression and GIN/GiST indexes.

✅ Indexing Best Practices

Index what you query — not every column/field needs an index.
Don’t over-index — too many indexes hurt writes (insert/update/delete).
Use compound indexes for multi-field filters/sorting.
Monitor usage with EXPLAIN ANALYZE (Postgres) or explain() (MongoDB).
Rebuild or drop unused indexes regularly.
Use partial indexes for conditional queries.
In MongoDB, avoid deep nested fields in indexes — they may not perform as expected.

🧩 Conclusion

Indexing isn’t just a performance booster — it’s a design strategy. Understanding how your database uses indexes under the hood helps you write better queries, build more scalable systems, and avoid bottlenecks. Whether you're working with a flexible document store like MongoDB or a powerful relational system like PostgreSQL, mastering indexing can make a huge difference in real-world applications.

Next time you're writing a query, ask yourself: "Is there an index for that?"

Why Use NVM? Manage Node.js Versions Like a Pro

Arnav Sharma — Sat, 05 Jul 2025 19:44:18 +0000

Ever been stuck with a project that only works with Node.js v14 while your system has v22?

That’s where NVM (Node Version Manager) saves the day. If you're a JavaScript or Node.js developer, using NVM is almost essential. Let's break down why you should use NVM and how to set it up in less than 5 minutes.

🤔 Why Use NVM?

1. Switch Between Node.js Versions Effortlessly

Projects often require different Node.js versions. With NVM, you can switch between them with a single command:

nvm use 18

2. Isolate Project Dependencies

Avoid global conflicts. Each project can use its own Node.js version, so you're never stuck debugging weird issues due to mismatched versions.

3. Avoid Breaking Global Installs

Upgrading Node globally can break tools like npm, yarn, or next. NVM keeps it safe by isolating installs.

4. Great for Open Source Contributions

Many open-source projects specify a Node.js version in .nvmrc. With NVM, all you need is:

nvm use

…and you're good to go.

🛠️ How to Install NVM (Mac/Linux)

Step 1: Install via cURL or Wget

# using curl
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

# or using wget
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Step 2: Add NVM to your shell profile

After installation, add this to your .bashrc, .zshrc, or .profile:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

Then restart your terminal or run:

source ~/.bashrc
# or
source ~/.zshrc

Step 3: Verify Installation

nvm --version

You should see something like 0.39.7.

⚡ Using NVM

Install a Node version

nvm install 20

Use a specific version

nvm use 20

Set default version

nvm alias default 20

Check installed versions

nvm ls

📁 Bonus: Use `.nvmrc` for Project-Level Versioning

Add a .nvmrc file in your project root:

echo "18" > .nvmrc

Now, whenever you're in the project directory:

nvm use

📦 Windows? Try `nvm-windows`

If you're on Windows, use the nvm-windows fork:

Download the installer from the release page
Follow the setup instructions
Done!

🚀 Final Thoughts

Whether you're working solo or contributing to multiple projects, NVM makes your Node.js workflow cleaner and safer. No more "version not supported" errors, no more global chaos.

MongoDB Transactions in Node.js: Complete Guide with Real Examples

Arnav Sharma — Sat, 05 Jul 2025 19:38:48 +0000

🔁 MongoDB Transactions in Node.js — The Complete Guide with Mongoose

If you think MongoDB isn’t meant for complex, multi-step operations like SQL transactions — think again.

With replica sets and sharded clusters, MongoDB supports ACID-compliant transactions. And in this blog, I’ll walk you through how to use them in a real-world Node.js backend.

👉 When Do You Even Need Transactions?

Let’s say:

You’re deducting money from one user and adding it to another.
You’re updating multiple collections together (like orders + inventory).
Or, you just want to make sure either everything is updated or nothing is.

MongoDB’s default operations are atomic only at the document level. If you need multi-document atomicity, transactions are your tool.

🧱 Setup

I'll be using Mongoose here. First, install it:

npm install mongoose

Connect to your database (make sure you're on a replica set):

mongoose.connect("mongodb://localhost:27017/your-db?replicaSet=rs0", {
  useNewUrlParser: true,
  useUnifiedTopology: true,
});

💼 Real-World Example: Wallet Transfer

Let’s build a simple transfer system between two users.

User Schema

const mongoose = require('mongoose');
const { Schema, model } = mongoose;

const userSchema = new Schema({
  name: String,
  balance: Number,
});

const User = model('User', userSchema);

🔁 Transaction Logic

Here’s how you’d do a transferMoney() function that updates both sender and receiver in a single transaction:

const transferMoney = async (senderId, receiverId, amount) => {
  const session = await mongoose.startSession();
  session.startTransaction();

  try {
    const sender = await User.findById(senderId).session(session);
    const receiver = await User.findById(receiverId).session(session);

    if (!sender || !receiver) throw new Error("User not found");

    if (sender.balance < amount) throw new Error("Insufficient balance");

    sender.balance -= amount;
    receiver.balance += amount;

    await sender.save({ session });
    await receiver.save({ session });

    await session.commitTransaction();
    console.log("✅ Transaction committed");
  } catch (err) {
    await session.abortTransaction();
    console.log("❌ Transaction aborted:", err.message);
  } finally {
    session.endSession();
  }
};

🧪 Try It Out

(async () => {
  await mongoose.connect("mongodb://localhost:27017/your-db?replicaSet=rs0");

  const alice = await User.create({ name: "Alice", balance: 100 });
  const bob = await User.create({ name: "Bob", balance: 50 });

  await transferMoney(alice._id, bob._id, 30);

  const updatedAlice = await User.findById(alice._id);
  const updatedBob = await User.findById(bob._id);

  console.log("Alice's balance:", updatedAlice.balance); // 70
  console.log("Bob's balance:", updatedBob.balance);     // 80
})();

⚠️ Common Mistakes

❌ Not using a replica set — transactions won't work on standalone MongoDB.
❌ Forgetting to pass the session into all operations inside the transaction.
❌ Trying to use transactions in high-throughput scenarios where performance is critical (transactions are slower).

🔄 Retry Pattern (Optional but Ideal)

In production, your transaction can fail due to transient network issues. Ideally, wrap your logic in a retry loop with exponential backoff.

You can also check for TransientTransactionError or UnknownTransactionCommitResult and reattempt.

✅ TL;DR

Use transactions when you're working with multi-document consistency.
Always wrap your logic inside session.startTransaction() / commitTransaction() / abortTransaction().
Keep transactions short, simple, and used only when necessary.

That’s it! This small trick can prevent big disasters in your backend logic.

If you liked this, I’ve also written about:
👉 Redis beyond SET and GET
👉 How Node.js handles concurrent requests

Let me know if you want a LinkedIn post version or carousel graphic too — happy to make one!

DEV Community: Arnav Sharma

How End-to-End Encryption Really Works: Understanding the Diffie–Hellman Key Exchange

🧩 The Core Idea

⚙️ How It Works (Step-by-Step)

🔒 Why It’s Secure

🌍 Real-World Uses

🧠 A Modern Twist: Elliptic-Curve Diffie–Hellman (ECDH)

🪄 The Takeaway

Browser Storage Explained: LocalStorage vs SessionStorage vs IndexedDB vs Cookies

🌐 1. LocalStorage

🕒 2. SessionStorage

📦 3. IndexedDB

🍪 4. Cookies

⚖️ Comparison Table

🚀 Final Thoughts

What Happens When You Type a URL in the Browser?

1. You Enter the URL

2. Browser Checks Cache

3. DNS Resolution (Domain → IP)

4. Browser Establishes a Connection (TCP Handshake)

5. Secure Connection (TLS Handshake for HTTPS)

6. Browser Sends HTTP Request

7. Server Processes the Request

8. Browser Receives the Response

9. Loading Extra Resources

10. You See the Page

⚡ TL;DR (Quick Recap)

🌐 Why Should You Care?

A/B Testing 101: A Beginner’s Guide to Smarter Decisions

What is A/B Testing?

Why A/B Testing Matters

How Does A/B Testing Work?

Components of a Strong A/B Test

Common Pitfalls in A/B Testing

Best Practices for A/B Testing

Beyond A/B: Advanced Testing

Real-World Examples

Key Takeaways

Understanding CORS: Why Your API Request Failed

What is CORS, really?

How does CORS actually work?

Why your request failed (common reasons)

How to fix CORS issues

1. Set CORS headers on the server

2. Use * in dev (but not in prod)

3. Enable credentials if needed

4. Use a proxy during development

Best Practices

Wrapping up

How SQL Queries Really Work: From Parsing to Execution

Introduction

1. Query Parsing

What Happens During Parsing?

Parse Tree Generation

2. Query Optimization

Logical Optimization

Cost-Based Optimization

Execution Plan Creation

3. Query Execution

Execution Engine Role

Key Steps in Execution

4. Real-World Example

5. Common Misconceptions About SQL Execution

“SQL just runs top to bottom” → Wrong.

Logical Order vs Execution Order

Actual Execution Order

6. Why This Knowledge Helps Developers

Conclusion

Pub/Sub Architecture: Push vs Pull Messaging (When to Use Each)

What is Pub/Sub?

Why Pub/Sub?

When Pub/Sub?

How Pub/Sub (Types)

🔹 Push-based Pub/Sub

🔹 Pull-based Pub/Sub

Comparison

Which Tech Uses Which One and How?

🐇 RabbitMQ (Push-based)

☁️ AWS SQS (Pull-based)

Real World Example

2. Use `*` in dev (but not in prod)

📝 Step 2: Create a `.proto` File

📁 Bonus: Use `.nvmrc` for Project-Level Versioning

📦 Windows? Try `nvm-windows`