DEV Community: Prism Infoways Private Limited

Idempotency Keys Explained: How to Make API Retries Safe (With Node.js and Redis Code)

Prism Infoways Private Limited — Fri, 09 Oct 2026 07:00:24 +0000

A customer taps "Pay" on a slow mobile connection. The request reaches your server, the card is charged, and then the response gets lost on the way back. The app sees a timeout and does what every well-behaved client does: it retries.

Now the customer has been charged twice.

Nothing in that story is a bug in the usual sense. The server worked. The client worked. The network did what networks do. The problem is that the client cannot tell the difference between "the request never arrived" and "the request succeeded but I never heard back." Retrying is the only sensible move, so the server has to make retrying safe.

That is what idempotency keys are for. This post covers how they work, the race condition most first implementations miss, and working Node.js code you can adapt.

What idempotency actually means

An operation is idempotent if doing it once has the same effect as doing it many times.

Some HTTP methods are idempotent by design:

GET /orders/42 reads data. Call it a hundred times and nothing changes.
PUT /users/7 with a full body sets the user to that state. Repeating it gives the same state.
DELETE /sessions/abc removes the session. The second call finds nothing to remove, and the end state is the same.

POST is the odd one out. POST /payments creates a new payment every time it runs. Two calls, two payments. The same goes for sending an email, placing an order, or issuing a refund.

You can't make these operations naturally idempotent, so you add a mechanism that lets the server recognise a repeat.

How idempotency keys work

The idea is simple:

The client generates a unique ID (a UUID is fine) for each logical operation, not for each HTTP attempt.
It sends that ID in a header, usually Idempotency-Key.
The server checks whether it has seen that key before.
If not, it processes the request and stores the response against the key.
If it has, it skips the work and returns the stored response.

POST /payments HTTP/1.1
Content-Type: application/json
Idempotency-Key: 7f3c2a9e-1b4d-4c8a-9e2f-5a6b7c8d9e0f

{ "amount": 4999, "currency": "INR", "orderId": "ord_812" }

The first request charges the card. Every retry with the same key gets the same response back, and the card is charged once.

The naive version and its race condition

Most first attempts look like this:

app.post("/payments", async (req, res) => {
  const key = req.get("Idempotency-Key");

  const cached = await redis.get(`idem:${key}`);
  if (cached) return res.json(JSON.parse(cached));

  const payment = await chargeCard(req.body); // slow
  await redis.set(`idem:${key}`, JSON.stringify(payment), "EX", 86400);

  res.json(payment);
});

It handles the easy case: a retry that arrives after the first request has finished.

It fails the hard case. Suppose the retry arrives while the first request is still inside chargeCard. Both requests run the get, both find nothing, and both charge the card. The check and the write are two separate steps, and anything can happen between them.

This is not rare. Aggressive client timeouts, double-clicks, and load balancer retries all produce two copies of a request within milliseconds of each other.

A safer Express middleware with Redis

The fix is to claim the key atomically before doing any work. Redis SET with the NX option does this: it writes only if the key doesn't exist, and tells you whether it won.

The middleware below also does two more things. It scopes keys to the user, so one customer can't collide with another. And it stores a hash of the request, so the same key reused with a different body is rejected instead of silently returning the wrong response.

const crypto = require("crypto");
const Redis = require("ioredis");

const redis = new Redis();

const LOCK_SECONDS = 60;          // how long a request may stay "processing"
const RESULT_SECONDS = 60 * 60 * 24; // how long a finished result is kept

function fingerprint(req) {
  return crypto
    .createHash("sha256")
    .update(req.method + req.originalUrl + JSON.stringify(req.body))
    .digest("hex");
}

function idempotency() {
  return async (req, res, next) => {
    const key = req.get("Idempotency-Key");
    if (!key) {
      return res
        .status(400)
        .json({ error: "Idempotency-Key header is required" });
    }

    const redisKey = `idem:${req.user.id}:${key}`;
    const hash = fingerprint(req);

    // Atomic claim: only one request can win this.
    const claimed = await redis.set(
      redisKey,
      JSON.stringify({ status: "processing", hash }),
      "EX",
      LOCK_SECONDS,
      "NX"
    );

    if (claimed !== "OK") {
      const raw = await redis.get(redisKey);
      const saved = raw ? JSON.parse(raw) : null;

      if (!saved || saved.status === "processing") {
        return res
          .status(409)
          .json({ error: "Request is already in progress. Retry shortly." });
      }

      if (saved.hash !== hash) {
        return res.status(422).json({
          error: "Idempotency-Key was already used with a different request",
        });
      }

      // Finished earlier: replay the stored response.
      return res.status(saved.code).json(saved.body);
    }

    // We own the key. Capture the response when the handler sends it.
    const sendJson = res.json.bind(res);
    res.json = (body) => {
      if (res.statusCode >= 500) {
        // Server failed: release the key so the client can retry.
        redis.del(redisKey).catch(() => {});
      } else {
        redis
          .set(
            redisKey,
            JSON.stringify({ status: "done", hash, code: res.statusCode, body }),
            "EX",
            RESULT_SECONDS
          )
          .catch(() => {});
      }
      return sendJson(body);
    };

    next();
  };
}

app.post("/payments", authenticate, idempotency(), async (req, res) => {
  const payment = await chargeCard(req.body);
  res.status(201).json(payment);
});

What each status code tells the client:

201 (or whatever the handler returned): done, whether this was the first attempt or a replay.
409: the original request is still running. Wait and retry with the same key.
422: the key was reused for a different request. This is a client bug, so don't retry.
5xx: the attempt failed and the key was released. Safe to retry.

When Redis is not enough: the database version

The middleware has one gap. The business write (the payment row) and the idempotency record live in two different systems. If the process crashes after the payment commits but before Redis is updated, the lock expires and a retry runs the handler again.

For most endpoints that window is acceptable. For money, it isn't. The stronger pattern is to store the key in the same database, in the same transaction, as the work itself:

CREATE TABLE idempotency_keys (
  user_id       BIGINT      NOT NULL,
  idem_key      TEXT        NOT NULL,
  request_hash  TEXT        NOT NULL,
  response_code INT,
  response_body JSONB,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  PRIMARY KEY (user_id, idem_key)
);

Inside one transaction, insert the key row, do the work, and save the response. The primary key makes the claim atomic: a second insert with the same key fails. And because everything commits or rolls back together, you can never end up with a payment that has no idempotency record.

If your handler calls an external provider such as a payment gateway, pass your key through to them as well. Most payment APIs accept an idempotency key of their own, which protects the one step your database transaction can't cover.

The client side: retrying with the same key

The server can only recognise a retry if the client sends the same key. Generate it once per operation, outside the retry loop:

async function createPayment(payload) {
  const key = crypto.randomUUID(); // once per operation, NOT per attempt

  for (let attempt = 0; attempt < 4; attempt++) {
    try {
      const res = await fetch("https://api.example.com/payments", {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "Idempotency-Key": key,
        },
        body: JSON.stringify(payload),
      });

      // Anything except "still processing" or a server error is final.
      if (res.status !== 409 && res.status < 500) {
        return res.json();
      }
    } catch (err) {
      // Network error or timeout: fall through and retry.
    }

    // Exponential backoff: 0.5s, 1s, 2s, 4s
    await new Promise((r) => setTimeout(r, 2 ** attempt * 500));
  }

  throw new Error("Payment request failed after retries");
}

In a web or mobile app, create the key when the user opens the checkout screen or taps the button, and keep it until the operation finishes. That way a double-tap or an app restart mid-request still reuses the same key.

Common mistakes

Generating a new key on every retry. This is the most common one, and it defeats the whole mechanism. Each attempt looks like a brand-new request.

Check-then-set without atomicity. A separate GET followed by SET leaves the race condition shown earlier. Use SET NX or a unique constraint.

Not scoping keys to the user. A global key namespace lets one client replay another client's response if keys collide or are guessed.

Ignoring the request body. If you don't compare a request hash, a client that reuses a key by mistake gets back a response for a completely different request.

Caching server errors. If you store a 500, the client can never recover with that key. Store successes and client errors; release the key on server errors.

No expiry. Keys kept forever grow without limit. 24 hours is a common retention window, since retries after that are almost never the same logical operation.

A lock that outlives nothing. If the "processing" marker has no TTL and the process crashes, the key is stuck in 409 forever. Always give the lock an expiry longer than your slowest request.

Checklist before you ship

Every non-idempotent write endpoint (payments, orders, emails, refunds) requires an Idempotency-Key.
The key is claimed atomically before any work starts.
Keys are scoped per user or per API client.
The request hash is stored and compared on replay.
In-progress requests return 409, mismatched bodies return 422.
Server errors release the key; successes are stored with a TTL.
Clients generate the key once per operation and reuse it on every retry.
For money, the key is written in the same transaction as the business data.

Idempotency is one of those things nobody notices when it works and everybody notices when it doesn't. It costs a few dozen lines of code up front, and it removes a whole class of duplicate-charge and duplicate-order bugs that are painful to clean up afterwards.

If you're building payment flows, order systems, or any API where a retry must not repeat the work, the team at Prism Infoways designs and builds backends with this kind of reliability built in from the start.

How do you handle retries in your APIs? Share your approach in the comments.

Caching Strategies Explained: Cache-Aside vs Write-Through vs Write-Behind (With Redis Code)

Prism Infoways Private Limited — Mon, 05 Oct 2026 05:24:00 +0000

A slow database query is one of the most common reasons a web app feels sluggish. Caching fixes it by keeping the answer in memory, so the next request skips the database. But the wrong caching strategy creates a new problem: users see stale prices, old profiles, or missing updates.

This guide explains the four caching strategies used in production: cache-aside, read-through, write-through, and write-behind. Each one comes with Node.js and Redis code, clear trade-offs, and the failure modes to plan for.

The Four Caching Strategies at a Glance

Cache-aside is the right default for most web apps. The other three solve specific problems it cannot.

Strategy	How it works	Best for	Main risk
Cache-aside	App checks the cache, falls back to the database, then fills the cache	Read-heavy data such as products, articles, API responses	Stale data until the TTL expires or the key is deleted
Read-through	The cache layer loads from the database itself on a miss	Same as cache-aside, with cleaner application code	Needs a library or provider that supports it
Write-through	Every write updates the database and the cache together	Data that is read right after it is written, such as profiles and settings	Slower writes, and memory spent on data nobody reads
Write-behind	Writes go to the cache first and reach the database later in batches	High-volume counters such as views, likes, and analytics events	Data loss if the cache fails before the flush

1. Cache-Aside (Lazy Loading)

In cache-aside, your application code manages the cache. It checks the cache first, reads the database only on a miss, and stores the result for next time.

The examples below use the redis npm client. db stands in for your own data layer.

import { createClient } from "redis";

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

async function getProduct(id) {
  const key = `product:${id}`;

  // 1. Try the cache first
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  // 2. Cache miss: read from the database
  const product = await db.products.findById(id);
  if (!product) return null;

  // 3. Store it for next time, with a TTL
  await redis.set(key, JSON.stringify(product), { EX: 300 });
  return product;
}

async function updateProduct(id, changes) {
  const product = await db.products.update(id, changes);
  await redis.del(`product:${id}`); // invalidate, don't update
  return product;
}

Notice that the write path deletes the key instead of updating it. If two requests update the same product at once, a delete can never leave an older value behind. The next read simply rebuilds the entry from the database.

Pros

Only data that is actually requested gets cached, so memory stays small.
If Redis goes down, the app still works. It just reads from the database.
It works with any database and any cache.

Cons

The first request for each key is slow, because it always misses.
Data can be stale until the TTL expires if you forget to invalidate on a write.
Caching logic gets repeated across your code unless you wrap it in a helper.

2. Read-Through

Read-through gives the same result as cache-aside, but the cache layer does the loading. Your code asks the cache for a key and never talks to the database directly.

You can get the same clean call sites with one small wrapper:

async function readThrough(key, ttl, loadFn) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const value = await loadFn();
  if (value != null) {
    await redis.set(key, JSON.stringify(value), { EX: ttl });
  }
  return value;
}

// Usage: one line per cached query
const product = await readThrough(`product:${id}`, 300, () =>
  db.products.findById(id)
);

The trade-offs match cache-aside. The gain is consistency: every cached query uses the same TTL rules, key format, and error handling.

3. Write-Through

Write-through updates the cache on every write, in the same operation as the database. Reads then almost always hit the cache, and they return fresh data.

async function saveProfile(userId, changes) {
  // Database first, so a failed write never reaches the cache
  const profile = await db.users.update(userId, changes);

  await redis.set(`user:${userId}`, JSON.stringify(profile), { EX: 3600 });
  return profile;
}

Use it when users read data straight after changing it. A profile page that shows the old name after a save is the classic bug this prevents.

It has two costs. Every write now does two operations, so writes get slower. You also cache records that may never be read, so always set a TTL to clear them out.

4. Write-Behind (Write-Back)

Write-behind sends each write to the cache only and saves it to the database later, in batches. The user gets an instant response, and the database sees one write instead of hundreds.

A page-view counter is a good fit:

async function recordView(postId) {
  // Fast path: touch the cache only
  await redis.incr(`post:${postId}:views`);
  await redis.sAdd("dirty:post-views", String(postId));
}

// Background worker: flush changed counters every 5 seconds
async function flushViews() {
  const ids = await redis.sPop("dirty:post-views", 500);

  for (const id of ids) {
    const views = await redis.get(`post:${id}:views`);
    await db.posts.update(id, { views: Number(views) });
  }
}

setInterval(flushViews, 5000);

A post that gets 1,000 views in five seconds now costs one database write, not 1,000.

The risk is data loss. Anything still waiting in the cache disappears if Redis crashes before the flush. Keep write-behind for data where losing a few seconds is acceptable, and never use it for orders or payments.

For heavier workloads, replace the simple set with a durable queue such as Redis Streams or Kafka. The worker can then retry a failed batch instead of dropping it.

Cache Invalidation and TTLs: Keeping Data Fresh

Every cached key needs two things: a TTL, and a plan for what happens when the source data changes. Skip either one and users will see stale data.

Always set a TTL. It is your safety net when an invalidation is missed. A key with no expiry can stay wrong forever.
Pick the TTL from the business rule. Ask how stale this data may be. A blog post can be minutes old. A stock count at checkout cannot.
Delete on write. When a record changes, delete its key in the same code path, as in the cache-aside example.
Use predictable key names. A format like product:42 or user:7:orders makes it easy to find what to delete.
Add jitter to TTLs. A small random offset stops thousands of keys from expiring in the same second.

// 300 to 359 seconds, so keys expire at different times
const ttl = 300 + Math.floor(Math.random() * 60);

Three Cache Failures to Plan For

Most caching bugs in production are one of three patterns. Each has a simple, well-known fix.

Cache stampede

A popular key expires, and hundreds of requests miss at the same moment. All of them run the same slow query, and the database stalls.

The fix is a short lock, so only one request rebuilds the value:

async function getWithLock(key, ttl, loadFn) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  // Only one request wins the lock
  const gotLock = await redis.set(`lock:${key}`, "1", { NX: true, EX: 10 });

  if (!gotLock) {
    // Someone else is rebuilding: wait briefly, then retry
    // (add a retry limit in production)
    await new Promise((resolve) => setTimeout(resolve, 100));
    return getWithLock(key, ttl, loadFn);
  }

  try {
    const value = await loadFn();
    await redis.set(key, JSON.stringify(value), { EX: ttl });
    return value;
  } finally {
    await redis.del(`lock:${key}`);
  }
}

Cache penetration

Requests keep asking for IDs that do not exist, such as /product/999999. Nothing is ever cached, so every request reaches the database. Bots and scrapers cause this often.

The fix is to cache the "not found" result for a short time:

if (!product) {
  await redis.set(key, "null", { EX: 30 }); // remember the miss
  return null;
}

Cache avalanche

A large share of keys expire together, or the cache restarts empty. The database suddenly takes the full traffic load.

TTL jitter, shown in the previous section, solves the first case. For the second, warm the most important keys at startup before sending traffic to the app.

How to Choose the Right Caching Strategy

Start with cache-aside and a TTL, then add another strategy only where a specific problem appears.

Mostly reads, and slightly stale data is fine? Use cache-aside. This covers product pages, articles, search results, and most API responses.
Users read data right after changing it? Add write-through for those records, such as profiles, settings, and carts.
Thousands of small writes per minute? Use write-behind, but only where losing a few seconds of data is acceptable.
Many cached queries across a large codebase? Wrap them in a read-through helper so every query follows the same rules.

Some things should not be cached at all:

Queries that already run in a few milliseconds. The cache adds complexity without a visible gain.
Values that must be exact at the moment of use, such as payment status or stock at checkout.
Data that is unique to each request and rarely repeated. The hit rate will be too low to matter.

Measure before and after. Track your cache hit rate and your slowest queries, and cache the few that cause most of the load.

Frequently Asked Questions

Which caching strategy is best?

Cache-aside is the best default for most web applications. It is simple, it survives a cache outage, and it only stores data that users actually request.

What is the difference between cache-aside and read-through?

The difference is who loads the data on a miss. In cache-aside, your application code queries the database and fills the cache. In read-through, the cache layer or a helper does it for you.

What is the difference between write-through and write-behind?

Write-through saves to the database immediately, as part of the same request. Write-behind saves to the cache first and updates the database later in batches. Write-through is safer, and write-behind is faster.

What TTL should I use for cached data?

There is no universal number. Start from how stale the data is allowed to be, then test. Many teams use minutes for content pages and hours for settings that rarely change.

Is Redis the only option for caching?

No. Memcached and Valkey work with the same patterns. A small in-process LRU cache is enough for a single server, and a CDN is the right cache for full HTTP responses.

Wrapping Up

Caching is one of the cheapest ways to make a web app faster, as long as the strategy fits the data. Use cache-aside by default, write-through where freshness matters, and write-behind only for high-volume writes you can afford to lose. Then set TTLs, add jitter, and protect hot keys from a stampede.

At Prism Infoways, we build and scale web applications for businesses worldwide. If your app is slowing down as traffic grows, our web development and cloud computing teams can help you find the bottleneck and fix it. You can reach us here.

Which caching strategy do you use in production, and what problems did it cause? Share your experience in the comments.

Rate Limiting Algorithms Explained: Token Bucket vs. Sliding Window (With Code)

Prism Infoways Private Limited — Fri, 25 Sep 2026 07:25:27 +0000

Almost every production API needs rate limiting eventually — to stop abuse, protect against traffic spikes, and keep one noisy client from degrading service for everyone else. Most tutorials tell you to add rate limiting, far fewer explain the actual tradeoffs between the different algorithms you could use. Picking the wrong one for your situation means either blocking legitimate traffic unnecessarily or failing to actually protect your system under load.

Here's a practical walkthrough of the main approaches, with working code for each.

Fixed Window Counter

The simplest approach: count requests in fixed time windows (e.g., per minute), reset the counter when the window ends.

import time

class FixedWindowLimiter:
    def __init__(self, max_requests, window_seconds):
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.requests = {}  # key -> (window_start, count)

    def allow(self, key):
        now = time.time()
        window_start = int(now // self.window_seconds) * self.window_seconds

        if key not in self.requests or self.requests[key][0] != window_start:
            self.requests[key] = [window_start, 0]

        self.requests[key][1] += 1
        return self.requests[key][1] <= self.max_requests

The problem: This has a well-known edge case — the "boundary burst" issue. If a client sends max requests at the very end of one window, and max requests again at the very start of the next window, they've effectively sent 2x their limit in a short burst spanning the boundary, and the algorithm never notices.

When it's still fine: For rough, low-stakes limiting where occasional boundary bursts don't matter much, fixed window is simple and cheap. Don't reach for something more complex than your actual requirement needs.

Sliding Window Log

Keeps a timestamp for every request in a rolling window, and counts how many fall within the last N seconds from now — not from a fixed boundary.

from collections import deque
import time

class SlidingWindowLogLimiter:
    def __init__(self, max_requests, window_seconds):
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.logs = {}  # key -> deque of timestamps

    def allow(self, key):
        now = time.time()
        if key not in self.logs:
            self.logs[key] = deque()

        log = self.logs[key]
        # Drop timestamps outside the current window
        while log and log[0] <= now - self.window_seconds:
            log.popleft()

        if len(log) < self.max_requests:
            log.append(now)
            return True
        return False

The tradeoff: This is accurate — no boundary burst problem — but it costs memory proportional to the number of requests per client per window, which can get expensive at high request volumes or with many distinct clients.

Sliding Window Counter (The Practical Middle Ground)

Approximates the sliding window log's accuracy without storing every timestamp, by blending the current and previous fixed-window counts, weighted by how far into the current window you are.

import time

class SlidingWindowCounterLimiter:
    def __init__(self, max_requests, window_seconds):
        self.max_requests = max_requests
        self.window_seconds = window_seconds
        self.windows = {}  # key -> {current_start, current_count, previous_count}

    def allow(self, key):
        now = time.time()
        current_start = int(now // self.window_seconds) * self.window_seconds

        state = self.windows.get(key)
        if state is None or state['current_start'] != current_start:
            previous_count = state['current_count'] if state and state['current_start'] == current_start - self.window_seconds else 0
            state = {'current_start': current_start, 'current_count': 0, 'previous_count': previous_count}
            self.windows[key] = state

        elapsed_in_current = now - current_start
        weight = 1 - (elapsed_in_current / self.window_seconds)
        estimated_count = state['previous_count'] * weight + state['current_count']

        if estimated_count < self.max_requests:
            state['current_count'] += 1
            return True
        return False

Why this is often the best default: It's memory-efficient (just two counters per client, not a log of every request), and it smooths out the boundary burst problem well enough for the vast majority of real use cases. This is what most production rate limiters (including the one built into many API gateways) actually use under the hood.

Token Bucket

A different mental model entirely: each client has a "bucket" that holds tokens, refilled at a steady rate. Each request consumes one token; if the bucket is empty, the request is rejected. This naturally allows short bursts (up to the bucket's capacity) while enforcing a steady average rate over time.

import time

class TokenBucketLimiter:
    def __init__(self, capacity, refill_rate_per_second):
        self.capacity = capacity
        self.refill_rate = refill_rate_per_second
        self.buckets = {}  # key -> (tokens, last_refill_time)

    def allow(self, key):
        now = time.time()
        tokens, last_refill = self.buckets.get(key, (self.capacity, now))

        elapsed = now - last_refill
        tokens = min(self.capacity, tokens + elapsed * self.refill_rate)

        if tokens >= 1:
            tokens -= 1
            self.buckets[key] = (tokens, now)
            return True

        self.buckets[key] = (tokens, now)
        return False

Why teams choose this: Token bucket is the natural fit when you genuinely want to allow bursts — a client that's been idle should be able to send a quick flurry of requests, as long as their average rate over time stays within budget. This maps well onto real usage patterns (a user rapidly clicking through a UI after being idle, for instance) better than a strict per-window count does.

Leaky Bucket (The Opposite Philosophy)

Where token bucket allows bursts, leaky bucket smooths them out — requests go into a queue (the "bucket"), and are processed at a constant, fixed rate, regardless of how bursty the incoming traffic is.

This is less commonly implemented as a simple in-memory limiter and more often realized through an actual request queue with a fixed-rate worker pulling from it — useful when you need to protect a downstream system that genuinely can't handle bursts at all, even brief ones (a legacy system with a hard concurrency limit, for example).

Choosing Between Them

Situation	Best fit
Simple, low-stakes limiting, don't want to over-engineer	Fixed window counter
Need accuracy and boundary bursts genuinely matter	Sliding window log (if volume is manageable) or sliding window counter (if not)
Want to allow natural bursts for idle-then-active clients	Token bucket
Protecting a downstream system that can't handle any burst at all	Leaky bucket / queue-based smoothing
Building a general-purpose API rate limiter with good default behavior	Sliding window counter

A Practical Note on Distributed Systems

Every example above assumes a single in-memory store. The moment you're running multiple API server instances behind a load balancer, in-memory counters per instance won't give you an accurate global rate limit — a client could get max_requests allowed on each instance. For distributed rate limiting, the same algorithms apply, but the counters need to live in a shared store (Redis is the common choice), typically implemented with atomic operations (INCR + EXPIRE, or a Lua script for the more complex sliding window variants) to avoid race conditions between instances.

Final Thoughts

There's no universally "correct" rate limiting algorithm — the right choice depends on whether you're optimizing for memory efficiency, accuracy, or burst tolerance, and what your downstream system can actually handle. Understanding the tradeoffs behind each approach, rather than reaching for whatever the first tutorial you find implements, is what makes the difference between rate limiting that actually protects your system and rate limiting that just adds complexity without solving the real problem.

Prism Infoways builds and audits backend systems and APIs, including rate limiting and abuse-protection strategies, for growing products. More at prisminfoways.com.

JWT vs. Session-Based Authentication: A Practical Guide for Choosing the Right One

Prism Infoways Private Limited — Wed, 09 Sep 2026 05:19:39 +0000

Every new backend project eventually hits the same fork in the road: JWT or sessions? Half the tutorials online will tell you JWT is the modern, scalable choice. The other half will tell you sessions are simpler and more secure. Both are right in different contexts, and picking wrong tends to bite you months later, once you're deep into a specific auth flow and the tradeoffs suddenly matter.

Here's an actual practical framework for choosing, not just a definitions list.

The Core Difference

Session-based auth stores session state on the server. When a user logs in, the server creates a session record (typically in a database or in-memory store like Redis), and sends the client a session ID in a cookie. On every request, the server looks up that ID to know who the user is.

Client                          Server
  |-- POST /login --------------->|
  |                                | creates session, stores in Redis
  |<-- Set-Cookie: sessionId=xyz --|
  |-- GET /profile (cookie) ----->|
  |                                | looks up sessionId in Redis
  |<-- user data ------------------|

JWT (JSON Web Token) auth is stateless. When a user logs in, the server issues a signed token containing the user's claims (ID, roles, expiry). The client sends this token on every request, and the server verifies the signature — no database lookup needed.

Client                          Server
  |-- POST /login --------------->|
  |                                | verifies credentials, signs JWT
  |<-- { token: "eyJhbGc..." } ---|
  |-- GET /profile (Bearer token)->|
  |                                | verifies signature, reads claims
  |<-- user data ------------------|

That one difference — state stored server-side vs. encoded in the token itself — is the root of almost every tradeoff between them.

Where Sessions Win

Instant revocation. If you need to log a user out immediately — forcibly, from the server side, say after a password change or a security incident — sessions handle this trivially: delete the session record, and the next request fails. With JWT, the token is valid until it expires, full stop, unless you build a separate revocation mechanism (more on that below).

Smaller client payload. A session cookie is just an ID — a few bytes. A JWT carrying several claims can be several hundred bytes to a few KB, sent on every single request.

Simpler mental model for traditional web apps. If you're building a server-rendered app where the browser and backend are tightly coupled, sessions are the more direct fit — this is what they were designed for.

Sensitive data stays server-side. Session data never leaves your server. A JWT's payload, by contrast, is base64-encoded, not encrypted — anyone with the token can decode and read the claims (they can't forge a valid signature, but they can read what's inside).

Where JWT Wins

Statelessness for horizontal scaling. Since the token carries everything needed to verify identity, any server instance can validate it without a shared session store. This matters a lot once you're running multiple backend instances behind a load balancer — sessions need a shared store (Redis, typically) to work across instances; JWT doesn't.

Cross-domain and mobile-friendly. Cookies get complicated across domains and don't map cleanly onto native mobile clients. A bearer token in an Authorization header works the same way regardless of client type or domain — which is why most public APIs and mobile backends default to token-based auth.

Natural fit for microservices. If you have multiple services that need to verify a user's identity independently, a JWT signed by a central auth service lets each downstream service verify the token locally, without calling back to a central session store on every request.

The Part Most Tutorials Skip: JWT Revocation

The single biggest practical problem with JWT is the one most getting-started guides gloss over: how do you log someone out before the token naturally expires?

A few real approaches, each with tradeoffs:

Short expiry + refresh tokens. Issue short-lived access tokens (5-15 minutes) alongside a longer-lived refresh token stored server-side. To "log out," you revoke the refresh token; the access token still works until it naturally expires, but that window is small.

// Access token: short-lived, stateless
const accessToken = jwt.sign({ userId, role }, ACCESS_SECRET, { expiresIn: '15m' });

// Refresh token: longer-lived, stored server-side so it CAN be revoked
const refreshToken = jwt.sign({ userId }, REFRESH_SECRET, { expiresIn: '7d' });
await db.refreshTokens.insert({ token: refreshToken, userId, revoked: false });

A denylist for the rare "must revoke immediately" case. For genuinely urgent revocations (compromised account), maintain a small, fast-lookup denylist (Redis, with a TTL matching the token's remaining life) of tokens or user IDs that should be rejected even if their signature is valid. This reintroduces a bit of the statefulness you were trying to avoid, but only for the exceptional case, not every request.

Version/generation numbers. Store a tokenVersion field on the user record. Include it as a claim in the JWT. On password change or forced logout, increment the version — any token issued before that increment fails validation on next check against the user record. This needs one lookup per request (or a cached version check), which is a smaller cost than a full session lookup.

A Practical Decision Guide

Your situation	Lean toward
Traditional server-rendered web app, single domain	Sessions
Public API consumed by third parties	JWT
Mobile app + backend	JWT
Microservices needing independent auth verification	JWT
Need instant, guaranteed logout/revocation	Sessions (or JWT + denylist)
Horizontally scaled backend, no shared session store set up	JWT
Already running Redis/shared cache for other reasons	Sessions become much simpler, tradeoff shrinks

The Honest Middle Ground

In practice, a lot of production systems end up as a hybrid: short-lived JWTs for stateless verification across services, backed by a server-side refresh-token record that gives you a real revocation point. You get most of JWT's scaling benefits without fully giving up the ability to say "this user is logged out, right now."

Don't pick JWT just because it's the trendier answer in tutorials, and don't pick sessions just because they're the "classic" choice. Pick based on whether you actually need statelessness (multi-instance scaling, cross-service verification, mobile/API clients) or whether instant revocation and simplicity matter more for your specific app. Most projects know the answer once they ask the question honestly.

Prism Infoways builds and audits authentication systems and backend architecture for growing products. If you're deciding on an auth strategy for a new build or fixing issues in an existing one, check out prisminfoways.com.

Native vs Cross-Platform App Development in 2026: Which Actually Saves You More Money?

Prism Infoways Private Limited — Sat, 29 Aug 2026 15:29:36 +0000

If you're planning a mobile app in 2026, you'll hit this question in your first client or product meeting: should you build native (separate iOS and Android codebases) or cross-platform (one codebase for both)?
The answer used to be simple — "native for anything serious, cross-platform for MVPs." That advice is outdated. Both Flutter and React Native shipped major architectural upgrades this year, and the gap that used to justify going native by default has narrowed a lot. This post breaks down what's actually different in 2026, what it costs, and how to decide without getting stuck in framework-war noise.

Native vs Cross-Platform: The Real Difference

Native app development means writing separate code for each platform — Swift/SwiftUI for iOS, Kotlin/Jetpack Compose for Android. Two codebases, two teams (or one team working twice), full access to every platform API on day one.
Cross-platform development means writing one codebase that compiles down to both platforms. In 2026, this space is really a two-horse race:

Flutter (Google) — compiles to native ARM code, draws every pixel itself through its own rendering engine
React Native (Meta) — renders using real native UI components, written in JavaScript/TypeScript with a React-based architecture A third option, Kotlin Multiplatform, is gaining traction for teams that want to share business logic while keeping fully native UI layers — worth knowing about, but still a niche choice for most product teams right now.

What Changed in 2026

Both major frameworks matured significantly this year, and it's worth understanding what actually changed before you pick a side:

Flutter now runs on its Impeller rendering engine by default (replacing the older Skia backend), which pre-compiles shaders and removes the first-run stutter Flutter was previously known for. Independent 2026 benchmarks put it at roughly 58–60 FPS on heavy, animation-rich UIs.
React Native completed its shift to the "New Architecture" — Fabric renderer, JSI bridge, and TurboModules are now the default for new projects, and bridgeless mode has eliminated the old JS-to-native communication bottleneck. React Native tends to cold-start faster (around 200ms) and uses somewhat less battery in recent test suites, since it renders through real native components rather than its own engine.
Flutter currently holds a larger share of the cross-platform market (roughly 46% vs React Native's 35–38%, per recent industry estimates), but React Native still draws from a much larger JavaScript developer pool, which matters more than market share when you're hiring. The honest takeaway from nearly every 2026 benchmark: for most business apps, the performance difference between the two is no longer the deciding factor. The decision should come down to your team, your UI complexity, and your platform roadmap — not which framework "wins" on paper.

Cost Comparison: What You're Actually Paying For

This is where the decision usually gets made in practice. Rough ranges for the Indian market in 2026:
App Type Native (iOS + Android) Cross-Platform (Flutter/RN)
Simple MVP (5–8 screens) ₹6–10 lakh ₹3–5 lakh
Mid-complexity app (e-commerce, booking, on-demand) ₹12–25 lakh ₹7–15 lakh
Complex app (fintech, real-time, heavy animation) ₹25 lakh+ ₹18–30 lakh
Cross-platform development typically saves 30–60% compared to building separate native apps, mainly because you're paying for one codebase and one QA cycle instead of two. That gap shrinks as app complexity grows — a highly complex app with platform-specific requirements can eat into cross-platform's cost advantage, sometimes to the point where native makes more sense anyway.
Other cost factors people forget to budget for:

Maintenance: one codebase is cheaper to maintain long-term, full stop.
Hiring: React Native developers are easier to find (and often cheaper) than Flutter developers in most Indian tech hubs, simply due to pool size.
Time-to-market: faster launch means faster revenue or faster investor traction — sometimes worth more than the raw development cost difference. When Native Actually Makes Sense Don't default to cross-platform just because it's cheaper. Go native when:
Your app is graphics- or camera-heavy (AR/VR, real-time video processing, complex custom animations)
You need day-one access to brand-new OS features (Apple/Google often ship platform-specific APIs to native SDKs first)
You're building for a single platform only, at least initially
Your product is performance-critical in a way that can't tolerate any abstraction layer — think trading apps, high-precision health devices, or hardware-heavy IoT companion apps

When Cross-Platform Is the Smarter Call

Cross-platform wins for the majority of business apps in 2026:

You need to launch on iOS and Android simultaneously with a limited budget
Your UI is standard (forms, lists, dashboards, e-commerce flows, content apps) rather than exotic
You're validating a product idea and need to move fast and iterate
Your team already knows JavaScript/React (favor React Native) or you want pixel-perfect design consistency across platforms and possibly web/desktop too (favor Flutter)

A Quick Decision Framework

Ask yourself these three questions, in order:

Do you need the app on both platforms within the same budget cycle? If yes, cross-platform is almost always the right call.
Is your UI graphics-heavy or does it need bleeding-edge OS features? If yes, lean native — or at least prototype the riskiest screen in both approaches before committing.
Does your team already have strength in JavaScript, Dart, or native Swift/Kotlin? Existing skill often matters more than theoretical framework advantages — a team that knows React will ship a better React Native app than a mediocre Flutter app, and vice versa.

The Bottom Line

In 2026, "native vs cross-platform" isn't a performance debate anymore — both paths are production-grade. It's a budget, timeline, and team-fit decision. Most growing businesses building their first or second app will get to market faster and cheaper with Flutter or React Native, and can always invest in native modules later for any screen that genuinely needs it.
The wrong move is picking a framework based on what's trending on social media instead of what your app, budget, and team actually need.

Choosing between native and cross-platform for your next app? Prism Infoways builds both — from Flutter and React Native MVPs to fully native iOS/Android apps — and can help you scope the right approach before you spend a rupee on development. Get a free consultation and see what fits your project.

Why Every Growing Business Needs a Web Development Partner, Not Just a Website Vendor in 2026

Prism Infoways Private Limited — Wed, 19 Aug 2026 05:50:12 +0000

Launching a new website is never as simple as people think. Getting the design right, keeping load times fast, ensuring mobile responsiveness, and nailing SEO — juggling all of this while still focusing on your core business is genuinely hard.

Common Mistakes Businesses Make Online

1. Focusing only on design
— A website should look good, but if it doesn't rank on Google, that design isn't doing much for your business.

2. Ignoring the mobile-first approach
— Over 70% of traffic today comes from mobile. If your site is slow or broken on mobile, users bounce almost instantly.

3. Treating security as an afterthought
— Cyber threats are increasing every year. Security needs to be built into the architecture from day one, not patched in later.

4. Bolting SEO on at the end
— SEO isn't something you add after launch; it should be baked into development from the start — clean code, fast load times, proper site structure.

What a Good Tech Partner Actually Does

A strong IT partner doesn't just hand you code — they understand your business goals and build around them:

Scalable architecture that grows with your business
Performance optimization
for consistently fast load times
SEO-friendly structure to help you capture organic traffic
Ongoing support
so technical issues never block your business

This isn't limited to web development alone. App development, AI/ML integration, cloud infrastructure, and digital marketing are all part of the same ecosystem when you're aiming for real end-to-end digital transformation.

Choosing the Right Partner

When evaluating an IT or web development company, look for:

A solid portfolio and genuine client reviews
Whether they build custom solutions or just rely on templates
Transparent pricing and clear timelines
Long-term support after launch, not just a handoff

Companies like Prism Infoways operate across this entire space — web development, app development, AI solutions, cybersecurity, and digital marketing — giving businesses a single reliable partner instead of juggling multiple vendors.

Final Thoughts

If you're serious about building your digital presence in 2026, don't just think "I need a website." Find a tech partner who can grow and evolve alongside your business.

Have you worked with a dedicated dev partner recently? Share your experience in the comments — what challenges did you run into?

Shopify vs WooCommerce vs Custom: How to Actually Choose for an Ecommerce Build

Prism Infoways Private Limited — Sat, 08 Aug 2026 13:38:58 +0000

The Platform Question Gets Asked Backwards, Usually

Most "Shopify vs WooCommerce vs custom" conversations start with a preference someone already has, and then look for reasons to justify it. A more useful starting point is the constraints of the actual project: catalog size, integration needs, budget, and who maintains the store after launch.
Here's how each option actually behaves under those constraints.

Shopify: Optimized for Speed to Launch, Not Flexibility

Shopify is a hosted, managed platform — you're renting infrastructure and a well-tested checkout flow in exchange for giving up some control.

Where it's the right call:

You need to launch fast and don't have in-house dev resources for ongoing platform maintenance
Your catalog and business logic are fairly standard (products, variants, standard shipping/tax rules)
You want PCI compliance, hosting, and uptime handled for you, not managed in-house

Where it starts to hurt:

Highly custom checkout flows or non-standard business logic (complex B2B pricing tiers, unusual bundling rules) fight the platform
Transaction fees stack up at scale unless you're on Shopify Payments
You're paying a recurring platform fee indefinitely, on top of app costs for anything beyond core features WooCommerce: More Flexibility, More Responsibility WooCommerce is a WordPress plugin — self-hosted, open-source, and far more customizable at the code level, but that flexibility comes with more to manage.

Where it's the right call:

You want full control over hosting, plugins, and custom functionality without platform fees
Your team (or dev partner) is comfortable managing WordPress security updates and plugin conflicts
You want lower long-term recurring costs, accepting more upfront setup work

Where it starts to hurt:

Plugin conflicts are a real, recurring maintenance cost — WooCommerce's flexibility comes from a large plugin ecosystem that doesn't always play well together
You're responsible for hosting performance, security patching, and backups (or paying someone to be)
Scaling a very large catalog can require more deliberate performance tuning than a hosted platform handles by default

Custom Build: Full Control, Full Cost

A fully custom platform means building the storefront, admin, and integrations from scratch (or from a headless commerce API like a custom backend with a decoupled frontend).
Where it's the right call:

Your business logic genuinely doesn't fit standard ecommerce patterns — complex pricing engines, unusual inventory rules, deep ERP/CRM integration
You're building at a scale where platform transaction fees or plugin limitations become a real cost problem
You need full control over performance and architecture (e.g., a headless setup for a highly custom frontend experience) Where it starts to hurt:
Cost and timeline are both significantly higher than the other two options
You now own the full maintenance burden indefinitely — security, scaling, updates, everything
It only pays off if the standard platforms genuinely can't serve your requirements — building custom because it "feels more professional" is usually a mistake Realistic Cost and Timeline Ranges These vary a lot by scope, but as a rough anchor for a mid-sized

business ecommerce build:

Approach Typical Cost Range Typical Timeline
Basic store (template-based) Lower end, budget-friendly 2–3 weeks
Standard store (custom design + integrations) Mid-range 4–6 weeks
Advanced/custom platform Higher investment 8–12 weeks
The biggest cost swing factor isn't usually the platform choice itself — it's the number of third-party integrations (payment gateways, shipping APIs, inventory/ERP systems) and how custom the design and business logic need to be.

A Practical Way to Decide

List your non-negotiable business logic first — pricing rules, integrations, workflows that can't be compromised on
Check if Shopify or WooCommerce handles that logic natively or via a well-maintained plugin/app
Only consider custom if the answer is genuinely no, not because custom sounds more impressive
Factor in who maintains this after launch — a platform choice that's cheap to build but expensive to maintain isn't actually the cheap option The right choice is almost always the one that matches your actual constraints, not the one with the most features or the most flexibility in the abstract.

This post is adapted from a longer guide covering full cost breakdowns and the development process step by step, originally published on the Prism Infoways blog: https://prisminfoways.com/blog-single/ecommerce-website-development-company-gurugram-cost-process

5 Practical Ways to Cut Cloud Hosting Costs for Small Business Web Apps

Prism Infoways Private Limited — Mon, 03 Aug 2026 06:53:53 +0000

If you're running a small business web app on AWS or Azure, there's a good chance you're paying more than you need to — not because of bad architecture decisions, but because of defaults nobody ever revisited after the initial setup.

Here are five things we've consistently found make the biggest difference when auditing cloud costs for small and mid-sized teams.

Right-size your instances (most teams over-provision by default)

It's common to spin up a t3.medium or m5.large "just to be safe" and never look back. Check actual CPU/memory utilization over a 2-week window using CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-xxxxxxxx \
  --start-time 2026-07-20T00:00:00Z \
  --end-time 2026-08-03T00:00:00Z \
  --period 3600 \
  --statistics Average

If average utilization is consistently under 20%, you're likely paying for capacity you don't use. Downsizing one tier often cuts compute costs by 30-40% with zero performance impact for typical CRUD apps.

Move static assets off compute instances entirely

Serving images, CSS, and JS directly from your app server wastes compute resources on something a CDN does better and cheaper. Moving static assets to S3 + CloudFront (or equivalent) usually:

Reduces origin server load
Cuts bandwidth costs significantly at scale
Improves page load times as a side benefit

Set up auto-scaling instead of running peak capacity 24/7

Most small business apps have predictable traffic patterns — busy during business hours, quiet overnight. Running peak-capacity instances around the clock means paying full price for idle time.

A basic auto-scaling group with scheduled scaling (not even reactive scaling) can cut costs meaningfully:

# Example: scale down overnight, scale up for business hours
ScheduledActions:
  - ScheduledActionName: scale-down-night
    Recurrence: "0 22 * * *"
    MinSize: 1
    MaxSize: 1
  - ScheduledActionName: scale-up-morning
    Recurrence: "0 8 * * *"
    MinSize: 2
    MaxSize: 4

Audit unused Elastic IPs, snapshots, and orphaned volumes

This one's boring but adds up fast. Unattached EBS volumes, old snapshots nobody deleted, and unused Elastic IPs quietly bill you every month. Run a quick audit:

aws ec2 describe-volumes --filters Name=status,Values=available
aws ec2 describe-addresses --query "Addresses[?AssociationId==null]"

We've seen accounts with 15-20% of their monthly bill coming from resources nobody was actively using.

Reserved Instances or Savings Plans for predictable workloads

If your baseline load is stable (not bursty), on-demand pricing is the most expensive way to pay for it. A 1-year Compute Savings Plan typically saves 30-40% over on-demand for workloads you know aren't going anywhere.

None of this requires a major re-architecture — it's mostly auditing what's already running and questioning defaults that were set once and forgotten. For most small business apps we've reviewed, steps 1, 2, and 4 alone typically recover 25-35% of monthly cloud spend without touching application code.

Based on cloud cost audits done at Prism Infoways, where we work with small and mid-sized businesses on cloud infrastructure and web development.