DEV Community: Sourav Bandyopadhyay

When Your API Ghosts You: A Deep Dive Into Idempotency in REST APIs

Sourav Bandyopadhyay — Sun, 04 Jan 2026 10:49:54 +0000

You know that sinking feeling when a user clicks "Pay" twice because the spinner froze—and your backend quietly double-charges them? That isn't "network unreliability." That's "we didn't design for idempotency."

In distributed systems, retries are not an edge case; they're the default path. Clients will retry. Proxies will retry. Your own code will retry. The only question is whether your system can handle it without corrupting state.

Situation: The "Phantom Double Charge"

You ship a payments API. A customer hits /payments with a POST, the network hiccups, your client never sees the 201, so it retries.

From your user's perspective:

"I clicked once. Your app broke."

From your database's perspective:

"I just created two payments, both valid, good luck explaining that."

The bug isn't in the retry. The bug is that the operation wasn't idempotent.

Task: Make Retries Boring

The real job is not "process this payment." The real job is "process this payment in a way that stays correct even if the same request hits us multiple times."

Idempotency means:

Multiple identical requests have the same effect as a single request.
After the first success, every duplicate is effectively a no-op in terms of system state.

Boring? Yes. That's the goal.

Action: Treat Requests Like Events, Not Wishes

Here's the simple move most teams skip: give each potentially destructive request a stable identity.

Typical Pattern:

Client generates an Idempotency-Key (UUID, payment intent ID, etc.)
Sends it with the POST:

   POST /payments HTTP/1.1
   Idempotency-Key: 123e4567-e89b-12d3-a456-426614174000
   Content-Type: application/json

   {"amount": 5000, "currency": "USD"}

Server logic:
- Check if this key has been seen before
- If not: process the request, store result keyed by Idempotency-Key
- If yes: return the previously stored response instead of processing again

Why This Works:

Network retries become safe—the second call is just a cache lookup
Client logic simplifies to: "retry until success or clear failure"
No more worrying about double side effects
Even if your database is eventually consistent, idempotency keys make this deterministic

Quick Implementation Pattern:

# Pseudocode for the idea

def process_payment(request_body, idempotency_key):
    # Check cache first
    cached_response = idempotency_cache.get(idempotency_key)
    if cached_response:
        return cached_response  # Already processed

    # Process only if new
    result = create_payment(request_body)

    # Store for future retries
    idempotency_cache.set(idempotency_key, result)

    return result

A note on HTTP semantics:

GET, PUT, DELETE are supposed to be idempotent by design
POST is not, which is why idempotency keys usually show up there
Some teams use idempotency keys for all mutable operations—even better

Result: Fewer Fires, More Sleep

Once you design around idempotency:

Payment "double charges" turn into "same payment, same receipt, every time."
Support tickets about "I only clicked once" quietly vanish
Retries become a reliability feature, not a reliability bug
Your team debugs 3 AM incidents with more confidence

Idempotency won't make your API exciting. It will make it trustworthy. And trust is what lets you ship faster without being afraid of your own error logs.

The Deeper Breakdown

If this resonates—if you're into the kind of "real-world backend hygiene"—idempotency, retries, failure modes, the unglamorous stuff that actually keeps systems up—then you might want to check out CoreCraft.

It's a newsletter focused on exactly this: concrete patterns, real trade-offs, code you can use tomorrow. No fluff, no vague "best practices," just battle-tested abstractions for working engineers.

👉 Read more at CoreCraft

Have a production idempotency horror story? Drop it in the comments. Let's normalize talking about this stuff.

Stop Confusing Replication and Sharding 🔥

Sourav Bandyopadhyay — Mon, 08 Dec 2025 12:56:59 +0000

Ever been in a meeting where someone says, “Let’s shard the database!” — and half the team nods like it’s obvious?

Yeah. That’s the problem.

🧩 The Real Problem

Replication and sharding are not the same.

Yet, they often get tangled together in early scaling conversations.

One scales reads.
The other scales writes. Mix them up, and you’ll over-engineer your app or burn nights debugging latency that didn’t need to exist.

Developers keep asking the wrong question:

“Should we shard or replicate?”

The right answer?

You probably need both — but at different stages of growth.

⚙️ The Action (When to Use Each)

Here’s the quick mental model you should carry into your next sprint:

Replication: Copy the same data across multiple nodes. Great for read-heavy systems.

→ Perfect when your users start outnumbering your database connections.
Sharding: Split your dataset across multiple servers. Great for write-heavy loads.

→ Use when your single-node writes start choking throughput.

Both are tools in your scaling toolkit — but each solves a distinct performance constraint.

🚀 The Solution (Stay Simple, Scale Smart)

Most apps don’t need sharding on day one.

If your Postgres instance still fits under 100GB and isn’t begging for mercy, sharding is premature optimization.

Start simple.

Vertically scale first.

Add replication when reads explode.

Shard only when writes become the bottleneck.

Build for today’s problem.

Architect for tomorrow’s.

That’s the short of it.

If you liked this breakdown, you’ll love the full version on CoreCraft — where we unpack complex backend topics with caffeine and curiosity.

Grab the full post 👉 Replication vs. Sharding: Stop Confusing Them

CoreCraft is a newsletter for tech thinkers who write — part debugging notes, part data architecture therapy, always tested before shipping.

When the Cloud Went Dark ☁️💥

Sourav Bandyopadhyay — Sun, 26 Oct 2025 05:08:56 +0000

15 hours of downtime.

17M+ outage reports across 60+ countries.

One DNS failure that brought the internet to its knees.

On October 19th, 2025, AWS US-EAST-1 didn't just have a bad day — it had a catastrophic collapse.

Snapchat froze. Roblox went dark. UK taxpayers couldn't file returns. Even smart mattresses stopped working (yes, really). Developer tools like Postman became unusable. A Premier League match got interrupted.

If you were building on AWS that day, you had a front-row seat to what happens when 70% of the world's internet traffic routes through a single point of failure.

This wasn't just an outage.

This was a brutal stress test of modern cloud architecture — and most of us failed it.

🎯 What This Teardown Covers

I spent weeks dissecting this incident, and here's what you'll discover:

The Technical Reality

Why multi-AZ deployments offered zero protection when the entire region went down
How a DNS resolution failure cascaded through DynamoDB → EC2 → IAM → everything else
The hidden architecture trap: your dependencies have dependencies (and those can fail too)

The Business Impact

Real numbers: How a mid-sized e-commerce site lost $62,500 in 15 hours
The companies nobody expected to go offline: Eight Sleep, Postman, UK HMRC tax portals
Why this outage obliterated annual SLA budgets by 17x

The Resilience Playbook

3 multi-region patterns (Active-Active, Active-Passive, Pilot Light) with cost-benefit breakdowns
Why teams with automated failover experienced a 3-minute incident while manual teams suffered 3-6 hours
The hard truth about multi-cloud: when it's overkill vs. when it's essential

The Bigger Picture

This isn't a one-off: Meta (2021), CrowdStrike (2024), Cloudflare-AWS (2025) — concentration risk is the pattern
How EU DORA and UK Critical Third Parties regulations are changing the game
Why "AWS-only expertise" is no longer enough in 2025

💡 Why This Matters to You

If you're building anything on the cloud, you're making a bet: that someone else's infrastructure will hold.

But here's what this outage taught us:

Your architecture is only as resilient as your weakest hidden dependency.

You can follow every AWS best practice. Deploy across multiple AZs. Implement health checks. Follow the Well-Architected Framework.

It won't matter if you're still in a single region when DNS fails.

This teardown isn't optional reading.

It's the mirror you need to hold up to your own system design before the next outage finds you unprepared.

🔑 Three Takeaways You Can't Ignore

1. Multi-AZ ≠ Multi-Region

AZs are rooms in a house. When the entire house floods, every room goes underwater.

You need multiple houses.

2. DNS Is the Silent Killer

It's not just "another service." When internal DNS fails, your entire cloud provider's ecosystem can become unreachable — even to their own engineers.

Every modern app has DNS as a hidden single point of failure.

3. Resilience Is a Design Choice, Not a Checkbox

The teams that survived this outage didn't get lucky. They designed for it.

They automated failover. They tested regional failures in production. They mapped every dependency.

They treated resilience as a first-class architectural concern.

📊 What Engineers Are Saying

"This is the most comprehensive breakdown of the October outage I've read. The section on hidden dependencies alone is worth the read."

— Senior SRE at a Fortune 500 company

"We ran our first full regional failover test after reading this. Found 3 critical gaps we didn't know existed."

— Platform Engineering Lead

"Forwarded this to our entire engineering org. Should be required reading for anyone designing cloud systems."

— CTO, Series B startup

🚀 Ready to Build More Resilient Systems?

This is just the beginning. At CoreCraft, we dig deep into the engineering decisions that separate bulletproof systems from fragile ones.

Want more insights like this?

👉 Read the full AWS US-EAST-1 teardown

👉 Subscribe to the CoreCraft newsletter for weekly deep-dives on cloud architecture, incident analysis, and engineering resilience

We cover:

Real-world outage autopsies with actionable lessons
Resilience patterns that actually work in production
The infrastructure decisions that make or break modern systems
Multi-cloud strategies, cost optimization, and scaling insights

No fluff. No vendor pitches. Just engineering truth.

💬 Let's Talk

Have you experienced a major cloud outage firsthand? How did your team respond?

Drop a comment below — I'd love to hear:

Your biggest cloud resilience challenge right now
Whether your team has run a full regional failover test (and what you learned)
Any hidden dependencies you discovered the hard way

And if this post helped you think differently about resilience, share it with your team. Every engineer should read this before the next outage hits.

📌 Quick Links

🔗 Full Teardown

📬 CoreCraft Newsletter

💼 Connect with us

P.S. If your team hasn't tested a full regional failover this quarter, it's already overdue. The next outage won't wait for you to be ready.

P.P.S. Downtime isn't just a technical problem — it's a trust problem. Every minute your service is offline, your competitors are online. Build resilience not because the cloud is unreliable, but because your customers' trust is irreplaceable.

Building resilient systems in 2025? Join 10,000+ engineers who trust CoreCraft for the insights that matter.

👉 Subscribe now and never miss a breakdown.

System Design Articles You Should Never Miss

Sourav Bandyopadhyay — Mon, 13 Oct 2025 05:33:33 +0000

Hey there! 👋 I'm Sourav, and I've been deep in the trenches of system design, backend engineering, and building things that actually scale. This is my curated collection of practical guides that'll help you move from "theory" to "shipped."

📚 My Core Articles on System Design

1. Scaling from Zero: Building Your First Production System

The foundational piece every engineer needs

Learn how to think about scalability from day one—before you even need it. We'll cover database design decisions, caching strategies, and why that microservices architecture isn't the answer... yet.

Read on Substack →

2. Database Design That Won't Bite You Later

Because schema changes at 3 AM are nobody's idea of fun

We'll walk through real examples of what breaks when you scale, why indexes matter more than you think, and how to avoid the "we need to rewrite our database" moment.

Read on Substack →

3. Caching Patterns That Actually Work

Redis, memcached, and when to say no to both

Cache invalidation is one of the hardest problems in computer science. Here's how to get it right without losing your mind. Plus, real code examples you can use tomorrow.

Read on Substack →

4. APIs That Don't Make People Hate You

RESTful design, versioning, and rate limiting for humans

A deep dive into designing APIs that are actually a pleasure to work with. We'll cover versioning strategies, error handling, and why your webhook implementation is probably broken.

Read on Substack →

5. Message Queues: When, Why, and How Not to Overcomplicate Them

Async processing that makes sense

RabbitMQ, Kafka, AWS SQS—they all have their place. Learn when to use them, when you're overengineering, and how to debug async systems when things go sideways.

Read on Substack →

🎯 The Quick Wins (Short Reads)

Handling Database Migrations in Production — Don't lock your tables. Here's how.

Monitoring > Hoping — Three metrics that matter more than you think.

The Anatomy of a Good Error Message — Because "something went wrong" won't cut it.

Load Balancing Without the Headache — Round-robin, least connections, and sticky sessions explained.

💡 Why You Should Follow CoreCraft

I write about the stuff that actually matters when you're building systems that users depend on. No fluff, no "10 tips" listicles—just real problems, real solutions, and code you can actually use.

Every week, I share:

Practical guides that go deep without being overwhelming
Real-world lessons from shipping products at scale
Code examples you can adapt to your stack
The "why" behind the "how" so you understand the tradeoffs

Whether you're architecting your first major system or debugging production issues, there's something here for you.

🚀 Next Steps

Want more like this? Subscribe to CoreCraft on Substack for weekly deep dives into system design, backend engineering, and building products that work.

I'm also active on Dev.to and happy to engage in the comments—ask questions, share your experiences, and let me know what topics you want to see explored next.

Your next system design breakthrough is waiting. Let's build it.

Follow @CoreCraft for the latest in system design and engineering blogs

Codex is Here to Slaughter Bad Code—And I’m Here for It 💥

Sourav Bandyopadhyay — Sun, 25 May 2025 19:10:37 +0000

Let’s be real: most coding tools are overhyped trash that promise the moon and deliver a buggy mess. Then comes Codex, the ChatGPT-powered coding assistant that’s not just another wannabe—it’s a straight-up code assassin.

🧠 Not Your Average Autocomplete Toy

Codex doesn’t suggest code—it writes it, clean and functional, faster than you can rage-quit a null pointer exception.

Got a bug haunting your repo for days? Codex sniffs it out and squashes it.
Need a pull request that doesn’t look like a weekend hackathon project? Done—it’s pristine.
Running on the cloud, so your wheezing laptop? Not its problem.

Whether you’re:

Hacking together your next MVP 💡
Wrestling legacy spaghetti 🤢
Or trying to ship anything before the next stand-up 🚨

Codex is like strapping a jet engine to your workflow.

📈 Why It’s a Game-Changer (And Not Just Another AI Toy)

I broke it all down in my latest Substack post:

✅ How Codex actually works under the hood
✅ Why it’s leaving other tools choking on dust
✅ Real-world dev use cases that seriously slap

👉 Read it here if you write code and breathe air:

https://www.link-trim.in/z5o9v1h2

🔥 Hot Take Time

Codex isn’t the future—it’s the present, and it’s brutal.

Are you sleeping on it, or already riding the wave? 🌊

🗯️ Drop your hottest takes in the comments:

What’s working
What sucks
Wild Codex moments you didn’t believe actually happened

Let’s geek out. 😈

Sharding vs. Partitioning: Stop Guessing, Start Building Scalable Systems

Sourav Bandyopadhyay — Fri, 09 May 2025 17:03:59 +0000

Spent 6 months debugging database bottlenecks? Wasted years on overhyped “silver bullet” scaling solutions?

80% of scaling attempts fail to deliver promised performance. 50% of teams misapply sharding or partitioning, tanking their systems.

Unbalanced shards, query latency spikes, data migration nightmares.

I’ve been a backend engineer for considerable amount of time, scaling systems at startups and Big Tech. I’ve seen databases choke, teams panic, and “experts” push buzzword-driven nonsense. No magic frameworks or AI-powered DBs. Just hard-earned truth from the trenches.

Here’s what works (and what doesn’t):

Sharding is for Horizontal Scale, Not Quick Fixes:
Pick sharding when your dataset is massive and you need to distribute it across nodes. Use consistent hashing to avoid hotspotting, and plan for rebalancing upfront. Shard smart, or you’re just splitting headaches.
Partitioning is for Query Efficiency, Not Infinite Growth: Use partitioning to break tables into manageable chunks for faster queries, but don’t expect it to scale indefinitely without sharding. Index wisely and monitor query plans._ Partition for speed, shard for scale._
Test Your Strategy Under Real Load: Simulate traffic spikes and node failures before going live. Tools like pgbench or Sysbench can expose weaknesses early. Theory is cute; load tests are brutal.

The full Sharding vs. Partitioning Guide (with full explanation on Substack) is free

No vendor-sponsored fluff or cookie-cutter tutorials. Just practical, no-BS advice for developers who want systems that scale without imploding.

P.S. If you want more like this, I write [no-nonsense, technical deep dives] on Substack. No fluff, just actionable insights.

Model Context Protocol (MCP)

Sourav Bandyopadhyay — Sat, 26 Apr 2025 17:49:24 +0000

How Model Context Protocol Is Rewriting the Rules of AI Integration

Imagine an AI that books flights, syncs calendars, and messages your team—all without a single line of code. That’s Model Context Protocol (MCP), the open standard turning AI into a seamless automation powerhouse.

What Is MCP?

Launched by Anthropic in late 2024, MCP is the USB-C of AI—a universal protocol letting models like Claude or ChatGPT connect to any app, database, or tool. No more custom API spaghetti.

Why it matters:

For devs: Skip API boilerplate—MCP servers handle Slack/GitHub/Postgres in minutes
For businesses: AI auto-generates reports from Shopify+Sheets+Slack
For creatives: Generate music in Ableton or tweak Figma designs via AI

Why MCP > Traditional Integrations

Without MCP, connecting AI means brittle one-off scripts. Gartner reports 70% of AI projects fail due to integration issues—MCP fixes this with:

✅ Standardized connections

✅ 10x faster development

✅ No-code automation

How It Works (In 10 Seconds)

AI (MCP Host) sends request
MCP Server (mini-adapter) talks to tools
Your app gets results—zero manual coding

The Future: MCP as AI’s HTTP

With OpenAI/Microsoft adopting it, expect:

Smart cities optimizing traffic via MCP
Personal agents managing health+groceries+schedules

Want the full technical deep dive?

→ Read on Substack

HTTP vs HTTPS: Why Website Security Matters

Sourav Bandyopadhyay — Mon, 21 Apr 2025 08:28:13 +0000

🚨 85% of Users Abandon "Not Secure" Websites—Here’s Why HTTPS Is Non-Negotiable

You’ve seen the warnings: "Not Secure" in red, a broken padlock, or worse—your browser blocking access entirely. If your site still runs on HTTP, you’re not just losing trust; you’re leaking data like a sieve.

HTTP vs. HTTPS: A Matter of Security & Survival

🔓 HTTP: The Digital Postcard

No encryption → Every login, credit card, and private message is sent in plain text.
Hacker’s playground → Anyone on the same Wi-Fi (coffee shop, airport) can intercept your data.
"Not Secure" warnings → Chrome, Firefox, and Safari actively scare users away.

🔒 HTTPS: The Bank-Grade Vault

End-to-end encryption → Scrambles data so only the intended recipient can read it.
SSL/TLS certificates → Prove your site is legit (no phishing clones).
Google loves it → Higher rankings, better SEO, and no scary warnings.

Why the Switch Isn’t Optional Anymore

🚨 Browser Blocking – Chrome/Firefox now block HTTP pages with forms.
📉 SEO Penalty – Google ranks HTTPS sites higher—HTTP is outdated.
💸 Lost Conversions – 92% of users avoid "Not Secure" sites.
⚡ Faster Performance – HTTPS enables HTTP/2 & HTTP/3 (faster loading).

How to Fix It (Before It’s Too Late)

Free SSL Certificates → Let’s Encrypt, Cloudflare.
Forced HTTPS Redirect → Ensure no one accesses the unsecured version.
Test Your Site → Use SSL Labs to check for vulnerabilities.

🚀 The Web Is Moving to HTTPS—Don’t Get Left Behind

If your site still runs on HTTP, you’re losing traffic, trust, and money. The fix? One hour of work for a lifetime of security.

👉 Want the full deep dive? Read the detailed guide on Substack to lock down your site today.

Single Point of Failure (SPOF)

Sourav Bandyopadhyay — Sat, 12 Apr 2025 05:22:03 +0000

In system design, redundancy is resilience, and SPOF—Single Point of Failure—is its arch-nemesis.

A SPOF is any individual component of a system that, if it fails, causes the entire system to go down. It’s the load balancer with no failover, the monolithic database with no replica, the EC2 instance that runs everything—alone.

Even in distributed systems, where we aim for high availability, SPOFs still lurk:

A single centralized cache layer (e.g., Redis) with no HA setup
DNS misconfiguration—yes, your whole stack can fall with that
A CI/CD pipeline bound to one region or one engineer's access

The irony? SPOFs are often born out of early optimization or technical debt disguised as speed.

🚨 Here's the thing...

I go deeper into real SPOF stories, failure modes, and how to design systems that don't panic under pressure over on my Substack.

If you're into:

Breaking down why systems fail
Learning practical patterns to avoid SPOFs
Applying resilience engineering in your architecture
👉 Then come hang out and subscribe here.

I promise it’s not just theory—it’s battle-tested lessons from the trenches.

JavaScript's Promise.race() for Efficient Asynchronous Operations

Sourav Bandyopadhyay — Mon, 18 Sep 2023 06:02:25 +0000

Introduction

Asynchronous operations are a common occurrence in modern web development. Whether you're dealing with API calls, timeouts, or load balancing, it's often crucial to respond quickly to the first completed operation. JavaScript's Promise.race() method provides an elegant solution to this challenge. In this article, we'll explore what Promise.race() is, its syntax, and practical use cases with examples to help you grasp its power.

Understanding `Promise.race()`

Promise.race() is a built-in JavaScript method designed to work with Promises. It takes an iterable, typically an array, containing multiple Promise objects and returns a new Promise. This new Promise resolves or rejects as soon as the first Promise within the iterable resolves or rejects. The value or reason for rejection of the first settled Promise becomes the settled value of the new Promise returned by Promise.race().

Syntax

Promise.race(iterable);

Practical Use Cases

Implementing Timeouts: One common use case for Promise.race() is implementing timeouts for asynchronous operations. Consider a scenario where you need to make an API call, but you want to ensure it responds within a certain time frame. You can achieve this using Promise.race():

const fetchWithTimeout = (url, timeout) => {
  const fetchPromise = fetch(url);
  const timeoutPromise = new Promise((_, reject) => {
    setTimeout(() => reject(new Error('Timeout')), timeout);
  });

  return Promise.race([fetchPromise, timeoutPromise]);
};

fetchWithTimeout('https://example.com/api/data', 5000)
  .then(response => console.log(response))
  .catch(error => console.error(error)); // Handles timeout or fetch errors.

In this example, the fetchWithTimeout function races the fetch operation with a timeout Promise. It resolves with the API response or rejects with a timeout error, allowing you to handle both scenarios.

Handling Multiple API Requests: When dealing with multiple API requests and you only care about the response from the fastest one, Promise.race() comes in handy:

const api1 = fetch('https://api1.example.com/data');
const api2 = fetch('https://api2.example.com/data');

Promise.race([api1, api2])
  .then(response => console.log(response)) // Resolves with the response of the first API to respond.
  .catch(error => console.error(error)); // Handles errors from both APIs.

In this case, the first resolved or rejected Promise among api1 and api2 will determine the fate of the race, allowing you to efficiently handle API responses.

Conclusion

JavaScript's Promise.race() is a powerful tool for managing asynchronous operations. It allows you to respond promptly to the first completed Promise, making it essential for scenarios where time is of the essence.

What is shadow DOM?

Sourav Bandyopadhyay — Sun, 26 Mar 2023 19:23:47 +0000

The Shadow DOM (Document Object Model) is a web standard that allows developers to create encapsulated and isolated DOM trees within an HTML document. Shadow DOM allows you to create components with their own DOM tree, styles, and behavior, which are completely separate from the rest of the document. It is a way to create components that are more robust, reusable, and maintainable.

The Shadow DOM is composed of two main parts: the Shadow DOM tree **and **the Shadow host.

The Shadow host is the element that contains the Shadow DOM tree, and the Shadow DOM tree is the DOM tree that is encapsulated within the Shadow host. The Shadow DOM tree can have its own styles, JavaScript, and other properties that are separate from the rest of the document.

One of the main benefits of using the Shadow DOM is that it allows you to create custom HTML elements with their own encapsulated styles and functionality. This means that you can create reusable components that are more robust and easier to maintain, without worrying about conflicting styles or behavior with other elements on the page.

Another benefit of using the Shadow DOM is that it allows you to create custom CSS properties and apply them to your Shadow DOM components. This means that you can create custom CSS properties that are specific to your components, which can help simplify your code and improve performance.

In summary, Shadow DOM is a web standard that allows developers to create encapsulated and isolated DOM trees within an HTML document. It provides a way to create reusable components with their own styles, behavior, and functionality, which are completely separate from the rest of the document.

Instance and Non-instance properties

Sourav Bandyopadhyay — Wed, 22 Mar 2023 09:57:30 +0000

In JavaScript, instance properties are properties that belong to an instance of a class or an object, while non-instance properties are properties that belong to the class or the object itself.

Instance properties are defined inside the class constructor using the "this" keyword, and they can be accessed and modified using the dot notation on an instance of the class:

class Person {
  constructor(name, age) {
    this.name = name; // instance property
    this.age = age;   // instance property
  }
}

const john = new Person("John", 30);
console.log(john.name); // "John"
john.age = 31;
console.log(john.age); // 31

Non-instance properties, on the other hand, are defined outside the class constructor or object literal using the class name or object name, respectively. They can be accessed and modified using the dot notation on the class or object itself:

// Class example
class Person {
  static species = "Homo sapiens"; // non-instance property
}

console.log(Person.species); // "Homo sapiens"

// Object example
const person = {
  name: "John",
  age: 30,
};

person.gender = "Male"; // non-instance property
console.log(person.gender); // "Male"

In the above example, Person.species is a non-instance property of the Person class, while person.gender is a non-instance property of the person object. Non-instance properties are typically used to define values that are shared among all instances of a class or all objects of a certain type.

DEV Community: Sourav Bandyopadhyay

When Your API Ghosts You: A Deep Dive Into Idempotency in REST APIs

Situation: The "Phantom Double Charge"

Task: Make Retries Boring

Action: Treat Requests Like Events, Not Wishes

Typical Pattern:

Why This Works:

Quick Implementation Pattern:

Result: Fewer Fires, More Sleep

The Deeper Breakdown

Stop Confusing Replication and Sharding 🔥

🧩 The Real Problem

⚙️ The Action (When to Use Each)

🚀 The Solution (Stay Simple, Scale Smart)

When the Cloud Went Dark ☁️💥

🎯 What This Teardown Covers

The Technical Reality

The Business Impact

The Resilience Playbook

The Bigger Picture

💡 Why This Matters to You

🔑 Three Takeaways You Can't Ignore

1. Multi-AZ ≠ Multi-Region

2. DNS Is the Silent Killer

3. Resilience Is a Design Choice, Not a Checkbox

📊 What Engineers Are Saying

🚀 Ready to Build More Resilient Systems?

💬 Let's Talk

📌 Quick Links

System Design Articles You Should Never Miss

📚 My Core Articles on System Design

1. Scaling from Zero: Building Your First Production System

2. Database Design That Won't Bite You Later

3. Caching Patterns That Actually Work

4. APIs That Don't Make People Hate You

5. Message Queues: When, Why, and How Not to Overcomplicate Them

🎯 The Quick Wins (Short Reads)

💡 Why You Should Follow CoreCraft

🚀 Next Steps

Codex is Here to Slaughter Bad Code—And I’m Here for It 💥

🧠 Not Your Average Autocomplete Toy

📈 Why It’s a Game-Changer (And Not Just Another AI Toy)

🔥 Hot Take Time

Sharding vs. Partitioning: Stop Guessing, Start Building Scalable Systems

Model Context Protocol (MCP)

How Model Context Protocol Is Rewriting the Rules of AI Integration

What Is MCP?

Why MCP > Traditional Integrations

How It Works (In 10 Seconds)

The Future: MCP as AI’s HTTP

Want the full technical deep dive?

HTTP vs HTTPS: Why Website Security Matters

HTTP vs. HTTPS: A Matter of Security & Survival

🔓 HTTP: The Digital Postcard

🔒 HTTPS: The Bank-Grade Vault

Why the Switch Isn’t Optional Anymore

How to Fix It (Before It’s Too Late)

🚀 The Web Is Moving to HTTPS—Don’t Get Left Behind

Single Point of Failure (SPOF)

🚨 Here's the thing...

JavaScript's Promise.race() for Efficient Asynchronous Operations

Introduction

Understanding Promise.race()

Syntax

Practical Use Cases

Conclusion

What is shadow DOM?

Instance and Non-instance properties

Understanding `Promise.race()`