DEV Community: shipra Shankhwar

Leetcode QOTD:- 3120. Count the Number of Special Characters I

shipra Shankhwar — Tue, 26 May 2026 04:03:47 +0000

Use two integers as bit masks:
- lower stores lowercase letters present.
- upper stores uppercase letters present.
Traverse each character in the string:
- If lowercase, set its corresponding bit in lower.
- If uppercase, set its corresponding bit in upper.
Perform lower & upper:
- Common set bits represent characters present in both lowercase and uppercase forms.
Use Integer.bitCount() to count total common bits and return the answer.

class Solution {
    public int numberOfSpecialChars(String word) {
        int lower = 0, upper = 0;

        for (char c : word.toCharArray()) {
            if (Character.isLowerCase(c))
                lower |= 1 << (c - 'a');
            else
                upper |= 1 << (c - 'A');
        }

        return Integer.bitCount(lower & upper);
    }
}

Leetcode QOTD:- 1871. Jump Game VII

shipra Shankhwar — Mon, 25 May 2026 13:23:44 +0000

Convert the string into a char array so reachable positions can be modified directly.
Start from index 0, since it is the starting reachable position.
Whenever the current index is reachable (i == 0 or marked as '2'):
- Try all jumps from i + minJump to i + maxJump.
- If a target position contains '0', mark it as '2' meaning “this index is reachable”.
j is not reset every time, so already checked ranges are skipped, helping achieve efficient traversal.
In the end, if the last index became '2', it means we successfully reached the end.

class Solution {
    public boolean canReach(String A, int minJump, int maxJump) {
    char[] s = A.toCharArray();
    int i = 0, j = 0;
    for (i = 0; i < s.length; ++i)
      if (i == 0 || s[i] == '2')
        for (j = Math.max(j, i + minJump); j <= Math.min((int) s.length - 1, i + maxJump); j++)
          if (s[j] == '0') s[j] = '2';
    return s[s.length - 1] == '2';
  }

  // O(N) time O(N) space
  public boolean canReach2(String A, int min, int max) {
    int N = A.length();
    boolean[] dp = new boolean[N];
    dp[0] = true;
    // cum: cumulated number of valid jump-from index in in [i - maxJump, i - minJump].
    int cum = 0;
    for (int i = min; i < N; ++i) {
      if (dp[i - min]) cum++;
      if (i - max - 1 >= 0 && dp[i - max - 1]) cum--;
      dp[i] = A.charAt(i) == '0' && cum >= 1;
    }
    return dp[N - 1];
  }
}

Interview Sheet Q3:- 217. Contains Duplicate

shipra Shankhwar — Sun, 24 May 2026 18:24:58 +0000

1. Brute Force Approach

Compare every element with every other element.
If any pair is equal → duplicate exists.

Time Complexity: O(n²)

Code

class Solution {
    public boolean containsDuplicate(int[] nums) {

        for (int i = 0; i < nums.length; i++) {

            for (int j = i + 1; j < nums.length; j++) {

                if (nums[i] == nums[j]) {
                    return true;
                }
            }
        }

        return false;
    }
}

2. Sorting Approach

Sort the array.
Duplicate elements will become adjacent.
Compare neighboring elements.

Time Complexity: O(n log n)

Code

import java.util.Arrays;

class Solution {
    public boolean containsDuplicate(int[] nums) {

        Arrays.sort(nums);

        for (int i = 1; i < nums.length; i++) {

            if (nums[i] == nums[i - 1]) {
                return true;
            }
        }

        return false;
    }
}

3. HashSet Approach (Optimal)

Why Optimal?

We only need fast checking of already seen elements.
HashSet gives near O(1) lookup and insertion.
Array is traversed only once.

Time Complexity: O(n)

Code

import java.util.HashSet;

class Solution {
    public boolean containsDuplicate(int[] nums) {

        HashSet<Integer> set = new HashSet<>();

        for (int num : nums) {

            if (set.contains(num)) {
                return true;
            }

            set.add(num);
        }

        return false;
    }
}

Leetcode QOTD:- 1340. Jump Game V

shipra Shankhwar — Sun, 24 May 2026 16:42:58 +0000

How to Think About This Problem

As we need to find the maximum number of indices we can visit by jumping left or right.

But there are conditions:

We can jump only up to distance d
We can jump only to a smaller value
If a bigger/equal value comes in between, movement stops

So from every index, we want to know:
“What is the maximum path I can create starting from here?”

That is a classic DFS + DP (memoization) pattern.

Why DFS?

At every index:

we try all valid left jumps
we try all valid right jumps
each jump again asks the same question:

“From this new index, how far can I go?”

This becomes a recursive exploration problem, so DFS fits naturally.

Why DP (Memoization)?

Without DP:

same index gets recalculated many times
recursion becomes very slow

Example:

index 5 may be reached from multiple paths
its answer will always remain same

So we store:
dp[i] = maximum jumps possible starting from index i

This avoids repeated work.

How This Approach Was Reached

We notice every index can independently act as a starting point.
From one index, we recursively explore all valid moves.
Same subproblems repeat → use memoization.
We need maximum path length → DFS returning best answer makes sense.

So final approach becomes:

DFS for exploration
DP for optimization

Logic

Create a dp[] array where:

dp[i] stores max jumps possible starting from index i

Start DFS from every index because answer can start anywhere.
In DFS:

initialize best = 1
minimum answer is the current index itself

Move right up to distance d:

if a bigger/equal element appears, stop (break)
otherwise recursively calculate jumps

Move left similarly:

stop when blocked by bigger/equal value

Update:
best = max(best, 1 + dfs(nextIndex))
Store result in dp[i] and return it.
Final answer is the maximum value obtained from all starting indices.

class Solution {
    int[] dp;

    public int maxJumps(int[] arr, int d) {
        int n = arr.length;
        dp = new int[n];

        int ans = 1;

        for (int i = 0; i < n; i++) {
            ans = Math.max(ans, dfs(i, arr, d));
        }

        return ans;
    }

    private int dfs(int i, int[] arr, int d) {
        if (dp[i] != 0)
            return dp[i];

        int best = 1;

        for (int nxt = i + 1; nxt <= Math.min(arr.length - 1, i + d); nxt++) {
            if (arr[nxt] >= arr[i])
                break;

            best = Math.max(best, 1 + dfs(nxt, arr, d));
        }

        for (int nxt = i - 1; nxt >= Math.max(0, i - d); nxt--) {
            if (arr[nxt] >= arr[i])
                break;

            best = Math.max(best, 1 + dfs(nxt, arr, d));
        }

        return dp[i] = best;
    }
}

Leetcode QOTD:- 1752. Check if Array Is Sorted and Rotated

shipra Shankhwar — Sat, 23 May 2026 12:05:59 +0000

Traverse the array and compare every element with the next element.
Use (i + 1) % nums.length so the last element can also compare with the first element.
In a sorted and rotated array, there can be only one position where: nums[i] > nums[i + 1]
Count such positions using didGetRotated. If count becomes greater than 1, return false; otherwise return true because the array is sorted and rotated at most once.

class Solution {
    public boolean check(int[] nums) {
        int didGetRotated = 0;
        int rotateInd = 0;
        for (int i = 0; i < nums.length; i++) {
            if ((nums[i] > nums[(i + 1)%nums.length]) && ++didGetRotated > 1) {
                return false;
            }
        }
        return didGetRotated <= 1;
    }
}

Interview Sheet Q2:- 121. Best Time to Buy and Sell Stock

shipra Shankhwar — Fri, 22 May 2026 05:21:40 +0000

Approach 1: Brute Force

Try every possible buy day.
For each buy day, try every sell day after it.
Calculate profit and keep maximum.

class Solution {
    public int maxProfit(int[] prices) {
        int maxProfit = 0;

        for (int i = 0; i < prices.length; i++) {
            for (int j = i + 1; j < prices.length; j++) {
                int profit = prices[j] - prices[i];
                maxProfit = Math.max(maxProfit, profit);
            }
        }

        return maxProfit;
    }
}

Complexity

Time: O(n²)
Space: O(1)

Approach 2: Optimal One Pass

Keep track of minimum price seen so far.
At every index:
- Calculate profit if sold today.
- Update maximum profit.
If current price is smaller, update minimum buy price.

Example:

Buy at 1
Sell at 6
Profit = 5

class Solution {
    public int maxProfit(int[] prices) {

        int minPrice = Integer.MAX_VALUE;
        int maxProfit = 0;

        for (int price : prices) {

            minPrice = Math.min(minPrice, price);

            int profit = price - minPrice;

            maxProfit = Math.max(maxProfit, profit);
        }

        return maxProfit;
    }
}

Complexity

Time: O(n)
Space: O(1)

Leetcode QOTD:- 33. Search in Rotated Sorted Array

shipra Shankhwar — Fri, 22 May 2026 05:12:39 +0000

Normally binary search works only on fully sorted arrays, but here one half is always sorted, and that is the key logic.

Main Idea

At every step:

Find mid
Check which half is sorted
Decide whether target lies inside that sorted half
Move accordingly

why this approach?

In a rotated sorted array:

At least one half is always sorted.
Using that sorted half, we can decide where target can exist.
So every iteration removes half the array.

complexity:

Time: O(log n)
Space: O(1)

class Solution {
    public int search(int[] a, int t) {

        int low = 0, high = a.length - 1;
        while (low <= high) {
            int mid = low + (high - low) / 2;
            if (a[mid] == t) {
                return mid;
            }
            if (a[low] <= a[mid]) {
                if (a[low] <= t && t <= a[mid]) {
                    high = mid - 1;
                } else {
                    low = mid + 1;
                }
            } else {
                if (a[mid] <= t && t <= a[high]) {
                    low=mid+1;
                }else{
                    high=mid-1;
                }
            }
        }
        return -1;
    }
}

Interview Sheet Q1:- 1. Two Sum

shipra Shankhwar — Thu, 21 May 2026 02:22:33 +0000

LeetCode: Two Sum

Given an array nums and a target, return indices of two numbers such that:

nums[i] + nums[j] == target

You can assume exactly one valid answer exists.

Approach 1: Brute Force

Logic

Check every possible pair in the array.

For each element:

Compare it with all next elements
If their sum becomes target → return indices

Time Complexity

O(n²)

Space Complexity

O(1)

Java Solution

class Solution {
    public int[] twoSum(int[] nums, int target) {

        for(int i = 0; i < nums.length; i++) {

            for(int j = i + 1; j < nums.length; j++) {

                if(nums[i] + nums[j] == target) {
                    return new int[]{i, j};
                }
            }
        }

        return new int[]{};
    }
}

Approach 2: HashMap (Optimal)

Logic

Instead of checking all pairs:

For every number:

Find what number is needed to reach target
Check if that number already exists in HashMap
If yes → answer found
Else store current number with its index

Example:

nums = [2,7,11,15]
target = 9

Current = 7
Need = 9 - 7 = 2

2 already exists in map
So answer = [index of 2, current index]

Why HashMap?

HashMap gives:

Fast search → O(1)
Fast insert → O(1)

So total becomes linear.

Time Complexity

O(n)

Space Complexity

O(n)

Java Solution

import java.util.HashMap;

class Solution {
    public int[] twoSum(int[] nums, int target) {

        HashMap<Integer, Integer> map = new HashMap<>();

        for(int i = 0; i < nums.length; i++) {

            int need = target - nums[i];

            if(map.containsKey(need)) {
                return new int[]{map.get(need), i};
            }

            map.put(nums[i], i);
        }

        return new int[]{};
    }
}

Approach 3: Sorting + Two Pointers

Logic

If array is sorted:

Small value at left
Large value at right

Then:

If sum is small → move left pointer
If sum is large → move right pointer
If equal → found

But problem asks for original indices, so we store:

value
original index

together before sorting.

Time Complexity

Sorting → O(n log n)
Two pointers → O(n)

Overall:

O(n log n)

Space Complexity

O(n)

Java Solution

import java.util.Arrays;

class Solution {

    public int[] twoSum(int[] nums, int target) {

        int[][] arr = new int[nums.length][2];

        // store value and original index
        for(int i = 0; i < nums.length; i++) {
            arr[i][0] = nums[i];
            arr[i][1] = i;
        }

        Arrays.sort(arr, (a, b) -> a[0] - b[0]);

        int left = 0;
        int right = nums.length - 1;

        while(left < right) {

            int sum = arr[left][0] + arr[right][0];

            if(sum == target) {
                return new int[]{arr[left][1], arr[right][1]};
            }

            else if(sum < target) {
                left++;
            }

            else {
                right--;
            }
        }

        return new int[]{};
    }
}

For interviews, the HashMap approach is the expected optimal solution.

Leetcode QOTD:- 3043. Find the Length of the Longest Common Prefix

shipra Shankhwar — Thu, 21 May 2026 02:12:10 +0000

Store all prefixes of numbers from arr1 in a HashSet.

Example for 12345:

12345
1234
123
12
1

We get these prefixes by repeatedly dividing by 10.

Then for every number in arr2, keep removing digits from the end and check if that prefix exists in the set.

Example:

1239 → 123 → found

So common prefix length = 3.

break is used because further prefixes (12, 1) will only be smaller.

import java.util.HashSet;

class Solution {
    public int longestCommonPrefix(int[] arr1, int[] arr2) {
        HashSet<Integer> prefixes = new HashSet<>();

        // Step 1: Insert all possible prefixes of numbers in arr1 into the HashSet
        for (int val : arr1) {
            while (val > 0) {
                prefixes.add(val);
                val /= 10; // Remove the last digit to get the next prefix
            }
        }

        int maxLength = 0;

        // Step 2: Check all possible prefixes of numbers in arr2 against the HashSet
        for (int val : arr2) {
            while (val > 0) {
                if (prefixes.contains(val)) {
                    // Step 3: If found, calculate its length and update maxLength
                    int currentLength = String.valueOf(val).length();
                    maxLength = Math.max(maxLength, currentLength);

                    // Optimization: Since we are dividing by 10, subsequent prefixes 
                    // of this specific 'val' will be shorter. We can break early.
                    break; 
                }
                val /= 10;
            }
        }

        return maxLength;
    }
}

Beginning a DSA Sheet for Technical Interview Preparation

shipra Shankhwar — Tue, 19 May 2026 13:24:27 +0000

As part of my interview preparation journey, I will be starting a DSA sheet focused on frequently asked and highly relevant coding interview questions from top product based companies such as Google, Amazon, Meta, Microsoft, Apple, and other FAANG level companies.

While preparing, I have been researching common interview patterns and important problem solving topics. I will be learning these concepts in depth and sharing my findings, approaches, and important questions along the way.

The sheet will include problems from areas such as Arrays, Graphs, Dynamic Programming, Trees, Sliding Window, Backtracking, and more, primarily using LeetCode questions that are widely asked in technical interviews.

Scaling from 10k to 1M Requests/Day(Every Layer That Matters)

shipra Shankhwar — Sun, 22 Mar 2026 13:45:13 +0000

Most systems don't collapse under load because of bad code.

They collapse because the architecture was never designed for order-of-magnitude growth.

Here's a breakdown of every layer, with patterns, tradeoffs, and code, that bridges the gap between 10k and 1M requests/day.

⚙️ Layer 1: The Data Layer Breaks First

At 10k req/day, a single RDBMS instance handles reads and writes without complaint.

At 1M, you hit lock contention, connection exhaustion, and query latency that compounds across every endpoint.

Read Replicas

Route all SELECT queries to replicas. Keep writes on primary.

-- On primary (write)
INSERT INTO orders (user_id, total) VALUES (42, 199.99);

-- On replica (read)
SELECT * FROM orders WHERE user_id = 42;

Watch for replication lag under heavy write load, a lagging replica can serve stale reads. Monitor with:

-- PostgreSQL: check replica lag
SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;

Connection Pooling with PgBouncer

Raw TCP connections to Postgres are expensive. At scale, hundreds of app instances opening direct connections will exhaust max_connections.

PgBouncer in transaction mode, each query borrows a connection from the pool, releases it immediately after. Reduces connection count dramatically.

# pgbouncer.ini
[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

CQRS: Separate Read and Write Models

Command Query Responsibility Segregation separates the write model (normalized, transactional) from the read model (denormalized, optimized for queries).

Write path:  API → Command Handler → Write DB (normalized)
                                          ↓ (event/sync)
Read path:   API → Query Handler  → Read DB (denormalized view)

Read models can be precomputed materialized views or even a separate datastore (e.g., Elasticsearch for search, Redis for leaderboards).

Composite and Partial Indexes

-- Composite index: covers multi-column WHERE + ORDER BY
CREATE INDEX idx_orders_user_created 
ON orders (user_id, created_at DESC);

-- Partial index: only indexes rows matching a condition
-- Much smaller, faster for filtered queries
CREATE INDEX idx_active_users 
ON users (email) 
WHERE status = 'active';

Always validate with EXPLAIN ANALYZE:

EXPLAIN ANALYZE 
SELECT * FROM orders 
WHERE user_id = 42 AND created_at > now() - interval '30 days';

Look for Seq Scan → that's a missing index. Index Scan → you're good.

⚡ Layer 2: Caching as an Architectural Layer

Every cache hit is a request your database, compute, and network never have to handle.

Cache-Aside Pattern (Lazy Loading)

The application checks the cache first. On a miss, it fetches from the DB and populates the cache.

async function getUser(userId) {
  const cacheKey = `user:${userId}`;

  // 1. Check cache
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // 2. Cache miss: fetch from DB
  const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

  // 3. Populate cache with TTL
  await redis.setex(cacheKey, 3600, JSON.stringify(user)); // 1 hour TTL

  return user;
}

Write-Through vs Write-Behind

Strategy	How it works	Best for
Write-through	Write to cache + DB synchronously	Read-heavy, consistency critical
Write-behind	Write to cache, async flush to DB	Write-heavy, latency sensitive

// Write-through
async function updateUser(userId, data) {
  await db.query('UPDATE users SET name=$1 WHERE id=$2', [data.name, userId]);
  await redis.setex(`user:${userId}`, 3600, JSON.stringify(data)); // sync
}

// Write-behind (async flush via queue)
async function updateUser(userId, data) {
  await redis.setex(`user:${userId}`, 3600, JSON.stringify(data));
  await queue.publish('db.write', { table: 'users', id: userId, data }); // async
}

Thundering Herd Prevention

When a hot cache key expires, thousands of requests can simultaneously hit the DB. This is the thundering herd problem.

Solution: Mutex on cache miss

async function getUserWithLock(userId) {
  const cacheKey = `user:${userId}`;
  const lockKey = `lock:${cacheKey}`;

  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Acquire lock: only one request hits the DB
  const lock = await redis.set(lockKey, '1', 'NX', 'EX', 5);
  if (!lock) {
    // Another request is fetching: wait and retry
    await sleep(100);
    return getUserWithLock(userId);
  }

  const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
  await redis.setex(cacheKey, 3600, JSON.stringify(user));
  await redis.del(lockKey);

  return user;
}

HTTP Caching Headers

Underused but extremely powerful. A properly cached API response never hits your origin.

HTTP/1.1 200 OK
Cache-Control: public, max-age=60, stale-while-revalidate=300
ETag: "abc123"
Last-Modified: Sun, 22 Mar 2026 10:00:00 GMT

max-age=60: serve from cache for 60 seconds
stale-while-revalidate=300: serve stale while refreshing in the background (zero perceived latency)
ETag: client sends If-None-Match: "abc123" on next request; server returns 304 Not Modified if unchanged

🔀 Layer 3: Async-First Architecture

The user doesn't need to wait for your email to send, your analytics to log, or your thumbnail to generate. Synchronous request-response for every operation is a design choice that doesn't survive scale.

Message Queue Pattern (SQS / RabbitMQ / Kafka)

// Producer: HTTP handler returns immediately
app.post('/orders', async (req, res) => {
  const order = await db.createOrder(req.body);

  // Don't wait: publish to queue and respond
  await sqs.sendMessage({
    QueueUrl: process.env.ORDER_QUEUE_URL,
    MessageBody: JSON.stringify({ orderId: order.id }),
  });

  res.status(202).json({ orderId: order.id }); // 202 Accepted
});

// Consumer: runs separately, processes async
async function processOrder(message) {
  const { orderId } = JSON.parse(message.Body);
  await sendConfirmationEmail(orderId);
  await updateInventory(orderId);
  await triggerAnalyticsEvent(orderId);
}

Dead Letter Queue (DLQ)

Failed messages should never be silently dropped. Route them to a DLQ for inspection and replay.

Normal Queue → Consumer fails 3x → Dead Letter Queue
                                          ↓
                                    Alert + manual replay

// SQS queue with DLQ configured
{
  "RedrivePolicy": {
    "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123:orders-dlq",
    "maxReceiveCount": 3  // Move to DLQ after 3 failures
  }
}

Idempotency Keys

At-least-once delivery means consumers may process the same message twice. Idempotent consumers handle this safely.

async function processOrder(message) {
  const { orderId, idempotencyKey } = JSON.parse(message.Body);

  // Check if already processed
  const alreadyProcessed = await redis.get(`processed:${idempotencyKey}`);
  if (alreadyProcessed) return; // Skip duplicate

  await fulfillOrder(orderId);

  // Mark as processed with TTL
  await redis.setex(`processed:${idempotencyKey}`, 86400, '1');
}

The Saga Pattern for Distributed Transactions

Traditional 2-phase commit (2PC) doesn't work across microservices. The Saga pattern replaces it with a sequence of local transactions, each with a compensating rollback action.

PlaceOrder Saga:
  1. Reserve inventory       → compensate: release inventory
  2. Charge payment          → compensate: refund payment
  3. Create shipment         → compensate: cancel shipment
  4. Send confirmation email → (no compensation needed)

If step 3 fails → run compensating transactions for steps 2 and 1.

🌐 Layer 4: Infrastructure That Scales Horizontally

Vertical scaling has a ceiling and a single point of failure. Horizontal scaling is the only path forward.

Stateless Services

Session state stored server-side makes horizontal scaling impossible. Any instance must be able to handle any request.

// ❌ Stateful: breaks with multiple instances
app.post('/login', (req, res) => {
  req.session.userId = user.id; // Stored in memory, instance-specific
});

// ✅ Stateless: works across any instance
app.post('/login', async (req, res) => {
  const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' });
  res.json({ token }); // Client holds state
});

Circuit Breaker Pattern

When a downstream service degrades, stop sending requests to it. Fail fast, return a fallback, allow recovery.

const CircuitBreaker = require('opossum');

const options = {
  timeout: 3000,         // If function takes > 3s, trigger failure
  errorThresholdPercentage: 50, // Open circuit if 50% of requests fail
  resetTimeout: 30000,   // After 30s, try again (half-open state)
};

const breaker = new CircuitBreaker(callPaymentService, options);

breaker.fallback(() => ({ status: 'queued', message: 'Payment queued for retry' }));

breaker.on('open', () => console.warn('Circuit OPEN: payment service degraded'));
breaker.on('halfOpen', () => console.info('Circuit HALF-OPEN: testing recovery'));
breaker.on('close', () => console.info('Circuit CLOSED: payment service recovered'));

// Usage
const result = await breaker.fire(paymentData);

States: CLOSED (normal) → OPEN (failing fast) → HALF-OPEN (testing recovery) → CLOSED

Bulkhead Pattern

Isolate resource pools per service or tenant. One overloaded consumer doesn't starve the rest of the system.

// Separate thread pools / connection pools per downstream service
const paymentPool = new ConnectionPool({ max: 10 });   // Max 10 connections to payment service
const inventoryPool = new ConnectionPool({ max: 20 });  // Max 20 to inventory service

// If payment service is slow and exhausts its pool,
// inventory service pool is completely unaffected.

📊 Layer 5: Observability is Infrastructure

You cannot debug a distributed system with console.log. At 1M req/day, observability is a prerequisite.

The Three Pillars

Pillar	Tool	Purpose
Metrics	Prometheus + Grafana	Aggregated numbers over time
Logs	ELK / Loki	Discrete events with context
Traces	Jaeger / OpenTelemetry	End-to-end request flow

RED Method for Services

Track Rate, Errors, Duration for every service.

const { Counter, Histogram } = require('prom-client');

const httpRequestsTotal = new Counter({
  name: 'http_requests_total',
  help: 'Total HTTP requests',
  labelNames: ['method', 'route', 'status_code'],
});

const httpRequestDuration = new Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request latency',
  labelNames: ['method', 'route'],
  buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5], // p50, p95, p99 visible here
});

app.use((req, res, next) => {
  const end = httpRequestDuration.startTimer({ method: req.method, route: req.path });
  res.on('finish', () => {
    httpRequestsTotal.inc({ method: req.method, route: req.path, status_code: res.statusCode });
    end();
  });
  next();
});

p95 and p99 latency matter more than averages at scale. An average of 50ms can hide that 1% of users are waiting 5 seconds.

Distributed Tracing with Context Propagation

Trace IDs must propagate across service boundaries: HTTP headers, queues, async jobs, to reconstruct the full request flow.

const { trace, context, propagation } = require('@opentelemetry/api');

// Outgoing HTTP request: inject trace context into headers
async function callInventoryService(orderId, headers = {}) {
  propagation.inject(context.active(), headers); // Injects traceparent header

  return fetch(`http://inventory-service/reserve/${orderId}`, { headers });
}

// Incoming request in inventory service: extract and continue trace
app.use((req, res, next) => {
  const ctx = propagation.extract(context.active(), req.headers);
  context.with(ctx, next); // All spans created in next() are children of caller's trace
});

SLO-Based Alerting

Alert on error budget burn rate, not raw error counts. This reduces alert fatigue and focuses on user impact.

# Prometheus alerting rule
- alert: HighErrorBudgetBurnRate
  expr: |
    (
      rate(http_requests_total{status_code=~"5.."}[1h]) /
      rate(http_requests_total[1h])
    ) > 0.01   # More than 1% error rate (if SLO is 99% success)
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Error budget burning too fast"

🔒 Layer 6: Security Surface Grows With Traffic

Scale makes you a target. The attack surface grows proportionally.

Rate Limiting: Token Bucket vs Leaky Bucket

Token bucket: allows bursting (user has 100 tokens, each request costs 1, refills at 10/sec)
Leaky bucket: enforces a steady output rate regardless of burst

const rateLimit = require('express-rate-limit');
const RedisStore = require('rate-limit-redis');

// Token bucket: allows short bursts
const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute window
  max: 100,            // 100 requests per window per IP
  standardHeaders: true,
  store: new RedisStore({ client: redis }), // Distributed: works across instances
  keyGenerator: (req) => req.headers['x-api-key'] || req.ip, // Per API key, fallback to IP
});

app.use('/api/', limiter);

Apply rate limiting at the edge (CDN/WAF level) before bad traffic reaches your app servers.

JWT Short-Lived Tokens + Refresh Rotation

Long-lived tokens are liabilities at scale. Stolen tokens remain valid for their full lifetime.

// Issue short-lived access token + longer-lived refresh token
function issueTokens(userId) {
  const accessToken = jwt.sign(
    { userId, type: 'access' },
    process.env.JWT_SECRET,
    { expiresIn: '15m' }  // Short-lived
  );

  const refreshToken = jwt.sign(
    { userId, type: 'refresh', jti: crypto.randomUUID() }, // jti = unique ID for rotation
    process.env.REFRESH_SECRET,
    { expiresIn: '7d' }
  );

  return { accessToken, refreshToken };
}

// On refresh-rotate: invalidate old, issue new
async function rotateRefreshToken(oldToken) {
  const decoded = jwt.verify(oldToken, process.env.REFRESH_SECRET);

  // Check token hasn't been used before (detect reuse attacks)
  const isRevoked = await redis.get(`revoked:${decoded.jti}`);
  if (isRevoked) throw new Error('Refresh token reuse detected');

  // Revoke old token
  await redis.setex(`revoked:${decoded.jti}`, 7 * 86400, '1');

  return issueTokens(decoded.userId);
}

The Architectural Mindset Shift

	10k req/day	1M req/day
Consistency	Strong consistency fine	Eventual consistency worth the tradeoff
Failures	Rare, handle manually	Expected, handle programmatically
Primary bottleneck	Application logic	I/O, network, database
Deployment	Downtime acceptable	Zero-downtime mandatory
Debugging	Logs are enough	Distributed tracing required
Scaling axis	Vertical	Horizontal + auto
Caching	Nice to have	Core architectural layer
Async processing	Optional	Default pattern

The gap between 10k and 1M isn't just infrastructure.

It's a shift from building features to designing for failure.

Redundancy, idempotency, backpressure, and observability aren't overengineering at this scale, they're the baseline.

Which layer tends to break first in your experience? data, async, or infra? Drop it in the comments.

The Great Reskilling: Why 2026 belongs to the "AI-Enhanced" Developer.

shipra Shankhwar — Thu, 19 Mar 2026 04:54:20 +0000

The headlines are hard to ignore lately. We’re seeing a massive wave of layoffs affecting "traditional" software roles, yet at the same time, the demand for AI-specialized talent is hitting record highs.

The reality? Companies aren't just cutting costs; they are reallocating them toward AI integration.

If you want to stay indispensable, you have to speak the language of the models. The good news? You don't need a $10k bootcamp to do it.

I just came across a game-changer: Anthropic Academy.

It’s a free learning platform from the creators of Claude, designed to take you from "AI-curious" to "AI-certified" without the price tag. Here’s why it’s worth your time:

Beat the Layoff Trend: While general dev roles are tightening, "AI Fluency" is becoming a mandatory requirement for high-paying positions in 2026.
Official Credentials: You get digital certifications directly from Anthropic to prove your expertise in prompting, AI ethics, and API integration.
Future-Proofing: It covers everything from basic productivity to building complex AI agents with the Model Context Protocol (MCP).

The gap between those who use AI and those who build with AI is widening. This is your chance to get on the right side of that curve for $0.

Check out Anthropic Academy and start building.

Has your team started prioritizing AI certifications yet? Let's discuss in the comments. 👇

SoftwareEngineering #AIJobs #Anthropic #ClaudeAI #CareerGrowth #TechLayoffs