DEV Community: Gouranga Das Samrat

Message Queues (SQS)

Gouranga Das Samrat — Sun, 12 Jul 2026 02:00:00 +0000

One-liner: A message queue decouples services by letting a producer drop messages into a queue, where consumers pick them up asynchronously — neither needs to be available at the same time.

📌 The Problem: Tight Coupling

User places order →
  [Order Service] → calls [Payment Service] → waits →
                  → calls [Email Service] → waits →
                  → calls [Inventory Service] → waits →
  All done! (3s total, 3 failure points)

Problems:

High latency — user waits for every downstream service
Cascading failure — if Email service is down, order fails
Tight coupling — Order service knows about all downstream services
No retry logic — failures are permanent

💡 The Solution: Message Queue

User places order → [Order Service] → DROP message in queue → RESPOND (fast!)
                                              ↓
                                   [Queue]
                                   /    |    \
                          [Payment] [Email] [Inventory]  ← process at their own pace

Benefits:

Decoupling — services don't know about each other
Resilience — downstream service can be down; message waits in queue
Load leveling — queue absorbs traffic spikes
Retry — failed processing retried automatically

🔄 Queue Concepts

Producer & Consumer

[Producer] → push message → [Queue] → pull message → [Consumer]

Producer: Creates and sends messages
Consumer: Reads and processes messages
Queue: Durable buffer between them

Message Lifecycle

1. Producer sends message → Queue stores it
2. Consumer polls queue → Queue marks message as "in-flight" (invisible to others)
3. Consumer processes → Success: Consumer deletes message
                     → Failure: After visibility timeout, message reappears

Visibility Timeout

Consumer pulls message → message hidden for 30 seconds
If consumer crashes → 30 seconds later, message reappears → another consumer picks it up
If consumer succeeds → consumer deletes message → gone forever

☁️ AWS SQS (Simple Queue Service)

Standard Queue

Unlimited throughput
At-least-once delivery — message may be delivered more than once!
Best-effort ordering — no strict FIFO

FIFO Queue

Exactly-once processing — deduplication
Strict ordering — first in, first out
Limited throughput — 300 msg/sec (or 3000 with batching)

SQS Key Concepts

Message retention:  Up to 14 days (default: 4 days)
Visibility timeout: How long consumer has to process (default: 30s)
Dead Letter Queue:  Where failed messages go after N retries
Max message size:   256 KB

SQS + Lambda (Serverless Consumer)

[SQS Queue] ──triggers──► [Lambda Function]
                           (auto-scales to process backlog)

🔀 Queue Patterns

Work Queue (Task Distribution)

[Producer] → [Queue] → [Worker 1]
                     → [Worker 2]
                     → [Worker 3]

Each message processed by exactly ONE worker

Use case: Image resizing, email sending, PDF generation

Fan-out via Multiple Queues

[Event] → [SNS Topic] → [Queue A] → [Consumer A]
                      → [Queue B] → [Consumer B]
                      → [Queue C] → [Consumer C]

Each consumer gets a copy of the message. (See: SNS/Pub-Sub)

Priority Queue

High priority queue → processed first by consumers
Low priority queue  → processed when high is empty

♻️ Dead Letter Queue (DLQ)

When a message fails to process after N retries → move to DLQ:

[Queue] → [Consumer fails 3 times] → [DLQ]
                                          ↑
                                    Ops team inspects,
                                    fixes bug, redrives

// SQS Redrive Policy
{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123:my-dlq",
  "maxReceiveCount": 3 // after 3 failures, move to DLQ
}

⚠️ Idempotency — Critical Requirement

Standard queues deliver at-least-once. Your consumer MUST be idempotent:

Message: "charge user 42 for $99"

❌ Non-idempotent: Just run the charge every time → user charged twice!
✅ Idempotent: Check if orderId already processed → skip if yes

async function processPayment(message) {
  const { orderId, userId, amount } = message;

  // Check idempotency key
  const alreadyProcessed = await redis.get(`payment:${orderId}`);
  if (alreadyProcessed) return; // skip duplicate

  await chargeUser(userId, amount);
  await redis.setex(`payment:${orderId}`, 86400, "1"); // mark done
}

📊 SQS vs Other Queues

Feature	AWS SQS	RabbitMQ	Apache Kafka
Type	Managed cloud	Self-hosted broker	Distributed log
Retention	14 days	Until consumed	Configurable (forever)
Ordering	Best-effort/FIFO	Per-queue	Per-partition
Replay	❌	❌	✅ (replay from offset)
Throughput	Very high	High	Very high
Use case	Decoupling tasks	Complex routing	Event streaming

🎨 Diagram

The diagram shows:

Producer → Queue → Multiple consumers
Visibility timeout flow (in-flight → reappear)
Dead Letter Queue after max retries
Fan-out via SNS → multiple queues

🔑 Key Takeaways

Queues decouple services and absorb traffic spikes
Visibility timeout ensures messages aren't lost if a consumer crashes
Always implement idempotent consumers with SQS Standard
DLQ is essential for debugging failed messages
Use FIFO when order matters; Standard when throughput matters

Redis

Gouranga Das Samrat — Sat, 11 Jul 2026 02:00:00 +0000

One-liner: An in-memory data structure store used as a cache, message broker, session store, rate limiter, and much more — blazing fast because everything lives in RAM.

📌 Why Redis?

Speed: In-memory → sub-millisecond latency (< 1ms)
Rich data types: Not just key-value — lists, sets, hashes, sorted sets, streams
Persistence: Optional — can snapshot to disk (RDB) or log every write (AOF)
Pub/Sub: Built-in message broker
Expiry: TTL on any key
Atomic operations: All commands are atomic

🗃️ Redis Data Types

String — The Basic Type

SET user:42:name "Rahul"
GET user:42:name      → "Rahul"
INCR page:views       → 1, 2, 3 (atomic counter)
SETEX session:abc 3600 "userId=42"  (with TTL)

Hash — Object/Map

HSET user:42 name "Rahul" age 25 city "Delhi"
HGET user:42 name      → "Rahul"
HGETALL user:42        → { name: Rahul, age: 25, city: Delhi }

Best for: User profiles, product data, config

List — Ordered, Allows Duplicates

LPUSH notifications:42 "You got a like!"  (push to left)
RPUSH notifications:42 "New follower!"    (push to right)
LRANGE notifications:42 0 9               (get first 10)
LPOP notifications:42                     (remove from left)

Best for: Activity feeds, queues (FIFO/LIFO), recent items

Set — Unordered, Unique Values

SADD followers:42 101 102 103
SMEMBERS followers:42    → {101, 102, 103}
SISMEMBER followers:42 102 → 1 (yes)
SCARD followers:42          → 3 (count)
SINTER followers:42 followers:99  → mutual followers (intersection)

Best for: Tags, unique visitors, friend lists

Sorted Set (ZSet) — Ranked/Scored Set

ZADD leaderboard 9500 "player_alice"
ZADD leaderboard 8700 "player_bob"
ZADD leaderboard 9900 "player_charlie"
ZRANGE leaderboard 0 2 WITHSCORES REV  → charlie(9900), alice(9500), bob(8700)
ZRANK leaderboard "player_alice"         → 1 (0-indexed rank)

Best for: Leaderboards, rate limiting, priority queues, trending topics

Stream — Append-only Log

XADD events * userId 42 action "purchase" amount 999
XREAD COUNT 10 STREAMS events 0

Best for: Event sourcing, activity logs, message queues (like Kafka-lite)

🏗️ Common Redis Use Cases

1. Session Store

// Login
redis.setex(`session:${token}`, 3600, JSON.stringify({ userId: 42 }));

// Per-request auth
const session = redis.get(`session:${token}`);

2. Cache (Cache-Aside)

const cached = await redis.get(`user:${userId}`);
if (!cached) {
  const user = await db.findUser(userId);
  await redis.setex(`user:${userId}`, 300, JSON.stringify(user));
}

3. Rate Limiting (Sliding Window)

const key = `rate:${userId}:${Math.floor(Date.now() / 60000)}`;
const count = await redis.incr(key);
await redis.expire(key, 60);
if (count > 100) throw new Error("Rate limit exceeded");

4. Pub/Sub Messaging

// Publisher
redis.publish(
  "notifications",
  JSON.stringify({ userId: 42, msg: "New order!" }),
);

// Subscriber
redis.subscribe("notifications", (message) => {
  const { userId, msg } = JSON.parse(message);
  sendPushNotification(userId, msg);
});

5. Distributed Lock

const lock = await redis.set("lock:resource", "1", "NX", "EX", 10);
if (!lock) throw new Error("Resource locked by another process");
// ... do work ...
redis.del("lock:resource");

NX = set only if Not eXists | EX 10 = expire in 10 seconds

6. Leaderboard

// Add/update score
redis.zadd("game:leaderboard", score, userId);

// Top 10
redis.zrange("game:leaderboard", 0, 9, "REV", "WITHSCORES");

// User's rank
redis.zrevrank("game:leaderboard", userId);

🔄 Redis Persistence

Mode	How	Data Safety	Performance
No persistence	Pure in-memory	Data lost on restart	Fastest
RDB (Snapshot)	Periodic snapshot to disk	Up to minutes of data loss	Fast
AOF (Append Only File)	Log every write to disk	Nearly no data loss	Slower
RDB + AOF	Both	Best safety	Moderate

# redis.conf
save 900 1      # Save if 1 key changed in 900 seconds
save 300 10     # Save if 10 keys changed in 300 seconds
appendonly yes  # Enable AOF

🏗️ Redis Cluster vs Sentinel

Redis Sentinel (High Availability)

[Sentinel 1] [Sentinel 2] [Sentinel 3]  ← monitors
      │
[Primary] ──replicates──► [Replica 1]
                         [Replica 2]

Automatic failover — promotes replica to primary
No sharding — all data on primary
Use for: HA without massive scale

Redis Cluster (Scale + HA)

[Node 1: slots 0-5460]     [Replica 1a] [Replica 1b]
[Node 2: slots 5461-10922] [Replica 2a] [Replica 2b]
[Node 3: slots 10923-16383][Replica 3a] [Replica 3b]

16,384 hash slots distributed across nodes
Built-in sharding + HA
Use for: Data larger than single machine's RAM

🎨 Diagram

The diagram shows:

Redis data types illustrated with examples
Cache-aside pattern
Redis Sentinel failover
Redis Cluster slot distribution

🔑 Key Takeaways

Redis is not just a cache — it's a data structure server
Sorted Sets for leaderboards/rankings are a killer feature
Always set TTLs — unbounded memory growth will kill your Redis
Use Sentinel for HA, Cluster for scale beyond single-machine RAM

Caching Strategies

Gouranga Das Samrat — Sun, 05 Jul 2026 02:00:00 +0000

One-liner: Caching stores the result of expensive operations (DB queries, API calls, computations) so future requests can be served instantly from fast memory instead of recomputing.

📌 Why Cache?

Without cache:
GET /user/42 → DB query (50ms) → response

With cache:
GET /user/42 → Redis lookup (1ms) → response  ← 50x faster!

Rule of thumb: RAM is ~100x faster than SSD, ~1000x faster than network DB calls.

🗺️ Caching Layers (From Client to DB)

[Browser Cache]          ← HTTP Cache-Control headers
      ↓ miss
[CDN Edge Cache]         ← Cloudflare, CloudFront
      ↓ miss
[Server-side Cache]      ← Redis, Memcached (in-memory)
      ↓ miss
[Database Query Cache]   ← MySQL query cache, Postgres
      ↓ miss
[Database Storage]       ← Actual data on disk

🔄 Cache Reading Strategies

Cache-Aside (Lazy Loading) — Most Common

Read:
1. Check cache → HIT → return data
2. If MISS → query DB → store in cache → return data

Write:
1. Write to DB
2. Invalidate (delete) cache entry

def get_user(user_id):
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)     # cache hit ✅

    user = db.query("SELECT * FROM users WHERE id = ?", user_id)
    redis.setex(f"user:{user_id}", 3600, json.dumps(user))  # cache for 1hr
    return user

✅ Only caches data that's actually requested
✅ Cache failure is tolerable — fall back to DB
❌ Cache miss penalty: 2 trips (cache + DB)
❌ Stale data possible after writes (until TTL or invalidation)

Read-Through

App → [Cache Layer] → [DB]
       (cache handles the DB lookup on miss)

The cache itself fetches from DB on miss. App only talks to cache.

✅ Simplified app code
❌ First request is always slow (cold start)

Write-Through

Write → Cache → DB (synchronously)

On every write, update both cache and DB synchronously.

✅ Cache always fresh
❌ Higher write latency (must write both)
❌ Writes cache entries that may never be read

Write-Behind (Write-Back)

Write → Cache → ACK to client
                     ↓ (async, later)
                    DB

Write to cache first, asynchronously flush to DB.

✅ Very fast writes
❌ Risk of data loss if cache crashes before flush
Use case: Analytics counters, view counts, likes

Write-Around

Write → DB (skip cache)
Read  → Cache → if MISS → DB → store in cache

Writes go directly to DB, bypassing cache. Cache is populated on read.

✅ Good for write-once, read-many data
❌ First read after write will miss cache

⚠️ Cache Eviction Policies

When cache is full, which items to remove?

Policy	How It Works	Best For
LRU (Least Recently Used)	Remove item not accessed for longest	General purpose (Redis default)
LFU (Least Frequently Used)	Remove least accessed item	When access frequency matters
FIFO	Remove oldest inserted item	Simple use cases
Random	Remove random item	When access pattern is uniform
TTL	Remove items past their expiry	Time-sensitive data

🕐 TTL (Time to Live)

Every cache entry should have a TTL — or you risk stale data forever.

Data Type	Suggested TTL
User session	30 minutes (sliding)
User profile	1–5 minutes
Product details	5–30 minutes
Search results	1–5 minutes
Homepage content	1–10 minutes
Static config/flags	1–24 hours
Rarely changing data	Days

💥 Cache Problems

Cache Stampede (Thundering Herd)

Popular cache key expires at exactly same time
→ 10,000 concurrent requests all miss cache
→ All hit the DB simultaneously
→ DB crashes

Fix: Probabilistic Early Expiration — randomly refresh before TTL expires:

remaining_ttl = redis.ttl(key)
if remaining_ttl < 30 and random() < 0.1:
    refresh_cache(key)  # Only 10% of requests refresh early

Or: Mutex/Lock — only one request fetches from DB on miss.

Cache Penetration

Requests for non-existent keys (e.g., userId=-999)
→ Always miss cache
→ Always hit DB
→ DB hammered with useless queries

Fix: Cache the null result too! redis.setex("user:-999", 60, "NULL")

Also: Bloom Filter — check if key exists before hitting DB.

Cache Avalanche

Many cache entries expire at the same time
→ Flood of DB queries simultaneously

Fix: Add jitter (random variation) to TTLs:

ttl = 3600 + random.randint(-300, 300)  # 3600 ± 5 minutes
redis.setex(key, ttl, value)

🔑 Key Takeaways

Default to Cache-Aside for reads — it's the most flexible
Always set a TTL — never cache indefinitely
Handle thundering herd, penetration, and avalanche in production
Cache only data that changes slowly and is read frequently

Reverse Proxy

Gouranga Das Samrat — Sat, 04 Jul 2026 02:00:00 +0000

One-liner: A reverse proxy sits in front of your servers, accepting client requests and forwarding them — hiding your actual server infrastructure.

📌 Forward Proxy vs Reverse Proxy

Forward Proxy: Client → [Proxy] → Internet
  (client uses proxy to reach internet — hides client)

Reverse Proxy: Client → [Reverse Proxy] → Servers
  (sits in front of servers — hides servers)

🛠️ What Reverse Proxies Do

Hide internal servers — clients never see real IPs
SSL termination — handle HTTPS, pass HTTP internally
Load balancing — distribute across backend servers
Caching — cache responses at proxy level
Compression — gzip responses
Static file serving — serve images/CSS/JS directly
Rate limiting — basic traffic control

🆚 Reverse Proxy vs API Gateway vs Load Balancer

Load Balancer: Distribute traffic (L4 or L7)
Reverse Proxy: Hide servers + SSL + static files + basic routing
API Gateway:   All of above + auth + rate limiting + transformation + monitoring

(In practice: Nginx can do all three)

📝 Nginx as Reverse Proxy

server {
    listen 443 ssl;
    server_name api.myapp.com;

    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;

    # Reverse proxy to Node.js app
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Serve static files directly (no proxy)
    location /static/ {
        root /var/www;
        expires 1y;
    }
}

Load Balancers

Gouranga Das Samrat — Sun, 28 Jun 2026 02:00:00 +0000

One-liner: A load balancer distributes incoming traffic across multiple servers so no single server becomes a bottleneck.

📌 Why Load Balancers?

Without:  [1000 req/sec] → [Server A] 🔥 (overloaded)
                         → [Server B] 💤 (idle)

With LB:  [1000 req/sec] → [Load Balancer]
                               ├──500 req/sec──► [Server A]
                               └──500 req/sec──► [Server B]

Benefits:

Prevents any one server from being overwhelmed
Enables horizontal scaling
Provides high availability — removes dead servers from rotation
SSL termination — offload TLS overhead from app servers

🔀 Load Balancing Algorithms

1. Round Robin

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A (cycles back)

✅ Simple, even distribution
❌ Doesn't account for server load or request weight

2. Weighted Round Robin

Server A (weight 3): gets 3 requests
Server B (weight 1): gets 1 request
Server C (weight 2): gets 2 requests

✅ Handles heterogeneous servers
❌ Still doesn't reflect real-time load

3. Least Connections

Server A: 100 active connections
Server B: 20 active connections  ← send here
Server C: 80 active connections

✅ Dynamic — adapts to actual load
✅ Great for long-lived connections (WebSockets)

4. IP Hash (Sticky Sessions)

hash(client_IP) % numServers → always same server

✅ Session affinity — user always hits same server
❌ Defeats purpose of stateless horizontal scaling
❌ Uneven if many users share same IP (corporate NAT)

5. Least Response Time

Routes to the server with the lowest combination of active connections + response time.

6. Random with Two Choices (Power of Two)

Pick 2 random servers, send to the one with fewer connections.
✅ Surprisingly close to optimal with very low overhead

🏗️ Layer 4 vs Layer 7 Load Balancers

Layer 4 (Transport Layer)

Works with TCP/UDP (IP addresses + ports)
Doesn't inspect packet content
Very fast, low overhead
Can't route based on URL path or headers

Sees: IP:port → forward to server

Layer 7 (Application Layer)

Works with HTTP/HTTPS content
Can route based on URL, headers, cookies
SSL termination here
Slower (more processing) but far more powerful

/api/*  → API servers
/static/* → Static file servers
/ws/*   → WebSocket servers

Example: Nginx as L7 LB

upstream api_servers {
    least_conn;
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    location /api/ { proxy_pass http://api_servers; }
    location /static/ { proxy_pass http://cdn_server; }
}

💓 Health Checks

LB constantly checks if servers are alive:

Passive: Monitor responses — if 5xx for 3 consecutive requests → mark unhealthy
Active:  Send GET /health every 10 seconds → expect 200 OK within 2 seconds

When a server is unhealthy → LB stops sending traffic. When it recovers → gradually re-added.

🔒 SSL Termination

Client ──[HTTPS]──► Load Balancer ──[HTTP]──► App Servers
         (encrypted)              (unencrypted, internal network)

Benefits:

App servers don't need SSL certificates
Reduces CPU overhead on app servers
Centralized certificate management

⚠️ Load Balancer as SPOF

The LB itself can become a SPOF!

Solution: Active-Passive LB Pair

[LB Primary] ──── health ────► [LB Secondary]
       │                              │
  (active)                    (standby — takes over if primary fails)
       └──────────────────────────────┘
                    VIP (Virtual IP floats between them)

🌍 Real Products

Product	Type	Use
Nginx	Software L4/L7	Self-hosted, versatile
HAProxy	Software L4/L7	High-performance, battle-tested
AWS ALB	Managed L7	AWS, auto-scaling integration
AWS NLB	Managed L4	Ultra-high performance, static IPs
Cloudflare	DNS + L7	Global, DDoS protection

🔑 Key Takeaways

LBs enable horizontal scaling and eliminate single points of failure
L7 LBs are more powerful but heavier; L4 LBs are faster
Least connections is usually the best algorithm for dynamic workloads
The LB itself needs to be made HA (active-passive pair)

CDN — Content Delivery Network

Gouranga Das Samrat — Sat, 27 Jun 2026 02:00:00 +0000

One-liner: A globally distributed network of servers that caches your static content close to users, dramatically reducing latency and offloading traffic from your origin server.

📌 The Problem

User in Mumbai → requests image from origin server in US-East
Latency: 200–300ms (round trip across the globe)

Multiply by: every image, CSS file, JS bundle, video chunk...
Result: Slow, painful experience

💡 The Solution: CDN

User in Mumbai → requests image
CDN Edge Node in Mumbai → serves cached image
Latency: 5–20ms (local)

CDN brings content closer to users by caching it at edge locations worldwide.

🗺️ CDN Architecture

                        [Origin Server - US]
                               │
              ┌────────────────┼────────────────┐
              │                │                │
        [Edge - Mumbai]  [Edge - London]  [Edge - Singapore]
              │
         [User - India] ← 15ms →

Cloudflare has 300+ edge locations. AWS CloudFront has 400+ PoPs (Points of Presence).

📦 What CDNs Cache

Static Assets (Always CDN-appropriate)

Images (JPEG, PNG, WebP, SVG)
JavaScript bundles (bundle.js)
CSS files (styles.css)
Fonts (.woff2, .ttf)
Videos (HLS/DASH streaming chunks)
HTML (for static sites)
PDF documents

Dynamic Content (Advanced CDN features)

API responses (short TTL — 1–5 minutes)
Personalized content (with Vary headers)
HTML with Edge Side Includes (ESI)

🔄 Cache Flow: CDN Request Lifecycle

Cache HIT (fast path)

User → CDN Edge → Cache HIT → Serve from edge

Cache MISS (slow path — first request)

User → CDN Edge → Cache MISS
               → Fetch from Origin Server
               → Store in edge cache
               → Serve to user

Cache INVALIDATION (when you deploy)

You push new bundle.js →
Signal CDN to invalidate old bundle.js →
Next request → MISS → fetches new version → caches it

⏱️ Cache Control Headers

The origin server controls CDN caching via HTTP headers:

# Cache for 1 year (immutable assets with content hash in filename)
Cache-Control: public, max-age=31536000, immutable

# Cache for 5 minutes (dynamic-ish content)
Cache-Control: public, max-age=300

# Don't cache (private user data)
Cache-Control: private, no-store

# Cache but validate with server first
Cache-Control: no-cache
ETag: "abc123"

Filename Hashing Strategy

bundle.js       → hard to cache long (changes on deploy)
bundle.a3f4c1.js → cache for 1 year (hash changes on deploy)

🔒 CDN Security Features

Feature	Description
DDoS Protection	Absorb volumetric attacks at edge (Cloudflare: 150+ Tbps capacity)
WAF	Web Application Firewall — block SQLi, XSS at edge
Bot Protection	Detect and block malicious bots
TLS Termination	Handle HTTPS at edge globally
Rate Limiting	Throttle requests at edge before they hit origin
Geo-blocking	Block traffic from specific countries

⚙️ CDN Configuration Example (Cloudflare)

Page Rules:
*.myapp.com/static/*  → Cache Everything, Edge TTL: 1 year
*.myapp.com/api/*     → Bypass Cache (dynamic)
*.myapp.com/*.html    → Cache, Edge TTL: 1 hour

🔄 Push vs Pull CDN

Pull CDN (Most Common)

Origin server remains the source of truth
CDN fetches content from origin on first request (cache miss)
Automatic — no manual upload needed
Examples: Cloudflare, CloudFront

Push CDN

You explicitly upload content to CDN
CDN serves it from edge; origin doesn't need to exist for every request
Good for known, large files (video, software downloads)
Examples: AWS S3 + CloudFront for uploads, Akamai NetStorage

🌍 Popular CDN Providers

Provider	Strength
Cloudflare	Best DDoS protection, free tier, 300+ PoPs
AWS CloudFront	Deep AWS integration, Lambda@Edge
Fastly	Real-time purging, developer-friendly
Akamai	Largest network, enterprise
BunnyCDN	Cheap, fast, developer-friendly

📊 CDN Impact on Performance

Without CDN (Mumbai user, US origin):

Latency: ~200ms
Origin bandwidth: 100GB/day

With CDN:

Latency: ~15ms (13× faster!)
Cache hit ratio: ~85%
Origin bandwidth: ~15GB/day (85% reduction)

🎨 Diagram

The diagram shows:

World map with edge nodes
Cache HIT vs MISS flows
Origin server → edge propagation
Cache-Control header on HTTP response

🔑 Key Takeaways

CDN = geographic caching — serve content from the closest edge node
Reduces latency, reduces origin load, handles DDoS
Use long TTLs + content hashing for static assets
Most modern apps should use a CDN from day 1 (Cloudflare free tier is excellent)

API Gateway

Gouranga Das Samrat — Sun, 21 Jun 2026 02:00:00 +0000

One-liner: A single entry point for all client requests that handles cross-cutting concerns like auth, rate limiting, routing, and logging — so your microservices don't have to.

📌 The Problem

In a microservices architecture, clients would need to call many services directly:

Mobile App → auth-service:3001
           → user-service:3002
           → order-service:3003
           → payment-service:3004
           → notification-service:3005

Problems:

Client needs to know every service's address
Auth logic duplicated in every service
CORS, rate limiting repeated everywhere
No single point for monitoring

💡 The Solution: API Gateway

Mobile App ──────────────► [API Gateway]
                                │
                                ├─► auth-service
                                ├─► user-service
                                ├─► order-service
                                └─► payment-service

The gateway is the single front door to your backend.

🛠️ What API Gateways Do

1. Request Routing

POST /auth/login      → auth-service
GET  /users/:id       → user-service
POST /orders          → order-service
GET  /products        → product-service

2. Authentication & Authorization

Client → [Gateway]
          → Validate JWT token
          → If invalid: 401 Unauthorized (request never hits services)
          → If valid: forward with user context

3. Rate Limiting

User A: 100 requests/min → allow
User A: 101st request    → 429 Too Many Requests

4. SSL Termination

Handles HTTPS at the gateway; internal traffic can be HTTP.

5. Request/Response Transformation

Client sends:  { "user_id": 123 }
Gateway transforms to: { "userId": "user_123", "timestamp": "..." }

6. Load Balancing

Routes to healthy instances of each microservice.

7. Caching

Cache responses at the gateway level for frequently accessed data.

8. Logging & Monitoring

Single place to log all incoming requests, response times, error rates.

9. Circuit Breaking

If a downstream service is failing, stop sending requests → return cached/fallback response.

10. API Versioning

/v1/users → old-user-service (v1)
/v2/users → new-user-service (v2)

🔄 Request Lifecycle Through Gateway

Client Request
    │
    ▼
[1] SSL Termination
    │
    ▼
[2] Authentication (JWT/OAuth validation)
    │
    ▼
[3] Rate Limiting Check
    │
    ▼
[4] Request Routing (which service?)
    │
    ▼
[5] Request Transformation (headers, body)
    │
    ▼
[6] Forward to Microservice
    │
    ▼
[7] Response Transformation
    │
    ▼
[8] Logging & Metrics
    │
    ▼
Client Response

⚖️ API Gateway vs Load Balancer

Feature	Load Balancer	API Gateway
Primary role	Distribute traffic	Smart routing + cross-cutting concerns
Layer	L4 or L7	L7 (always)
Authentication	❌	✅
Rate limiting	Limited	✅
Request transformation	❌	✅
Circuit breaking	❌	✅
Routing by path	L7 only	✅
Overhead	Low	Higher

Often used together: LB in front of API Gateway for the gateway's own HA.

⚖️ API Gateway vs Reverse Proxy

Feature	Reverse Proxy	API Gateway
Purpose	Forward requests, hide servers	Orchestrate microservices
Auth	❌	✅
Business logic	Minimal	Yes (routing rules, transforms)
Example	Nginx, HAProxy	Kong, AWS API Gateway

🌍 Popular API Gateway Products

Product	Type	Best For
Kong	Open source	Self-hosted, plugin ecosystem
AWS API Gateway	Managed	AWS ecosystem, serverless
Nginx	Open source	Can be configured as gateway
Traefik	Open source	Docker/Kubernetes native
Apigee	Enterprise	Google Cloud, enterprise features
Azure API Management	Managed	Azure ecosystem

⚠️ Gateway Pitfalls

Pitfall	Impact	Fix
Gateway is SPOF	If gateway dies, everything dies	Run multiple instances behind LB
Too much logic in gateway	Gateway becomes a monolith	Keep it thin — only cross-cutting concerns
High latency	Every request passes through gateway	Optimize, cache at gateway, keep logic light
Tight coupling	Gateway knows too much about services	Use routing rules, not business logic

🎨 Diagram

The diagram shows:

Client → Gateway → multiple microservices
Auth, Rate Limiting, Logging modules inside gateway
Gateway cluster (multiple instances) behind a load balancer
Circuit breaker to a failing service

🔑 Key Takeaways

API Gateway = single entry point + cross-cutting concerns
Move auth, rate limiting, logging out of services and into the gateway
The gateway can become a bottleneck/SPOF — make it HA and keep it lightweight
Don't put business logic in the gateway — that belongs in services

SQL vs NoSQL

Gouranga Das Samrat — Sat, 20 Jun 2026 02:00:00 +0000

One-liner: SQL databases store data in structured tables with strict schemas; NoSQL databases trade strict consistency for flexibility and horizontal scalability.

📌 SQL (Relational Databases)

Core Properties

Structured — Data in tables with rows and columns
Schema — Fixed structure, must be defined upfront
ACID — Atomicity, Consistency, Isolation, Durability
Relations — Foreign keys, JOINs across tables
Query Language — SQL (standardized)

Examples

Database	Best For
PostgreSQL	Complex queries, JSONB support, general purpose
MySQL	Web apps, e-commerce
SQLite	Local/embedded, mobile apps
Oracle	Enterprise, banking
MS SQL Server	Microsoft ecosystem

When to Use SQL

✅ Complex queries with JOINs
✅ Strong consistency required (banking, payments)
✅ Data is relational by nature (users → orders → products)
✅ ACID transactions needed
✅ Data structure is well-known and unlikely to change

📌 NoSQL (Non-Relational Databases)

Core Properties

Flexible schema — Add/remove fields without migrations
Horizontally scalable — Designed to scale out
Eventual consistency — Usually (some offer strong consistency)
Optimized for specific access patterns

Types of NoSQL

1. Document Store

// MongoDB, CouchDB, Firestore
{
  "_id": "user_123",
  "name": "Rahul",
  "address": { "city": "Delhi", "pin": "110001" },
  "tags": ["premium", "verified"]
}

Best for: User profiles, product catalogs, CMS

2. Key-Value Store

Redis, DynamoDB, Memcached
"session:abc123" → { userId: 42, expiry: ... }
"counter:pageviews" → 1000000

Best for: Sessions, caching, real-time counters, leaderboards

3. Column-Family Store

Cassandra, HBase
Row key → { column1: val, column2: val, column3: val }

Best for: Time-series data, IoT, write-heavy workloads, Netflix viewing history

4. Graph Database

Neo4j, Amazon Neptune
Nodes (Person) → Edges (FOLLOWS) → Nodes (Person)

Best for: Social networks, fraud detection, recommendation engines

⚖️ The Comparison

Dimension	SQL	NoSQL
Schema	Fixed	Flexible
Horizontal scaling	Hard	Easy
Transactions	Full ACID	Often eventual consistency
JOINs	Easy	Avoid (denormalize)
Query flexibility	High (SQL)	Limited to access patterns
Learning curve	Moderate	Varies by type
Maturity	50+ years	15–20 years

🔄 ACID vs BASE

ACID (SQL)

Property	Meaning
Atomicity	All or nothing — transaction either fully succeeds or fully fails
Consistency	DB always goes from one valid state to another
Isolation	Concurrent transactions don't interfere
Durability	Once committed, data survives crashes

BASE (NoSQL)

Property	Meaning
Basically Available	System always responds (maybe stale data)
Soft state	State can change over time, even without input
Eventually consistent	System will eventually be consistent

🏗️ Choosing Between SQL and NoSQL

Decision Tree:

Is the data relational?
├── Yes → SQL (start here)
└── No ↓
    Do you need flexible schema?
    ├── Yes → Document (MongoDB)
    └── No ↓
        Is it write-heavy time-series?
        ├── Yes → Column (Cassandra)
        └── No ↓
            Is it graph-traversal heavy?
            ├── Yes → Graph (Neo4j)
            └── No → Key-Value (Redis/DynamoDB)

🌍 Real-World Usage Patterns

Company	SQL	NoSQL
Uber	PostgreSQL (trips)	Cassandra (location updates)
Netflix	MySQL (billing)	Cassandra (viewing history)
Instagram	PostgreSQL (user data)	Redis (feed cache)
Twitter	MySQL	Redis (timeline), Cassandra (tweets)
Airbnb	MySQL	ElasticSearch (search)

Most large systems use both — polyglot persistence!

🔑 Key Takeaways

Default to SQL for new projects — better tooling, stronger guarantees
Move to NoSQL when you hit specific scale/flexibility walls
Most production systems use both (polyglot persistence)
NoSQL doesn't mean "no schema" — you still have implicit structure

Read Replicas

Gouranga Das Samrat — Sun, 14 Jun 2026 02:00:00 +0000

One-liner: Copies of your primary database that handle read queries, freeing the primary to focus on writes.

📌 The Problem

Most web applications are read-heavy (80-90% reads, 10-20% writes).

A single database server handles both reads and writes → becomes a bottleneck.

All traffic → [Primary DB]
              CPU: 95% 🔥
              Connections: maxed out 🔥

💡 The Solution: Read Replicas

Add secondary copies of the database:

Primary (Master) → handles all writes
Replicas (Slaves) → handle all reads

[App Server 1] ──write──► [Primary DB] ──replicates──► [Replica 1]
[App Server 2] ──read──►  [Replica 1]                 [Replica 2]
[App Server 3] ──read──►  [Replica 2]

🔄 How Replication Works

Synchronous Replication

Write → Primary → waits for Replica ACK → confirms to client

✅ Zero data loss — Replica always has latest data
❌ Higher write latency — must wait for replica confirmation

Asynchronous Replication

Write → Primary → confirms to client → replicates to Replica in background

✅ Lower write latency
❌ Replica lag — reads might return slightly stale data
❌ If primary crashes before replication, data loss possible

Semi-Synchronous

Write → Primary → waits for ACK from at least 1 replica → confirms

Balance between safety and latency (MySQL's default option)

📊 Replication Lag

Replica lag is the delay between a write on primary and it being visible on replica.

Lag	Impact
< 100ms	Usually fine — imperceptible to users
100ms – 1s	Acceptable for most use cases
> 1s	Noticeable — "I just posted but I can't see it" bug
Minutes	Data consistency issue — investigate urgently

Handling Lag in Code

// Read-after-write consistency:
// After a user writes, route their next read to primary

async function getUserProfile(userId, justUpdated = false) {
  if (justUpdated) {
    return await primaryDB.query("SELECT * FROM users WHERE id = ?", [userId]);
  }
  return await replicaDB.query("SELECT * FROM users WHERE id = ?", [userId]);
}

🏗️ Architecture Patterns

Single Replica (Simple)

Writes → [Primary] → [Replica 1] ← Reads

Multiple Replicas (Common)

         [Primary] ──► [Replica 1]  \
Writes →      │    ──► [Replica 2]  ──► Read traffic distributed
              └────► [Replica 3]  /

Cascading Replicas

[Primary] → [Replica 1] → [Replica 2] → [Replica 3]

Reduces load on primary but increases replica lag.

Regional Replicas (Multi-region)

[Primary - Mumbai] ──► [Replica - Singapore]
                   ──► [Replica - US-East]

Serve reads from the closest region to the user.

🔄 Failover: When Primary Dies

Detect failure — health check fails
Elect new primary — replica with least lag is promoted
Redirect writes — app/load balancer routes writes to new primary
Old primary rejoins — becomes a replica when it comes back

Before: App → Primary(A) → Replica(B)
Failure: Primary(A) dies
After:  App → Primary(B)   [B promoted]
              ↑
           Replica(A) [A rejoins as replica]

⚠️ Read Replica Caveats

Caveat	Detail
Eventual consistency	Reads may return stale data
Write bottleneck	Replicas help reads; writes still limited to primary
Complex routing	Need to distinguish read vs write queries
Cost	Each replica = another database server

🌍 When to Add Read Replicas

DB CPU > 70% sustained → add replica
Read:Write ratio > 5:1 → add replica
Reporting queries slowing down app → add dedicated analytics replica
Multi-region users → add geo-replica

🎨 Diagram

The diagram shows:

Primary DB receiving writes
Replication arrows to 2-3 replicas
App servers routing reads to replicas
Failover promotion flow

🔑 Key Takeaways

Read replicas solve read scalability — writes still bottleneck on primary
Use async replication for performance, sync for zero data loss
Always handle replica lag in your application code
Read replicas are the first step; sharding is the next if writes bottleneck

Database Sharding

Gouranga Das Samrat — Sat, 13 Jun 2026 02:00:00 +0000

One-liner: Splitting a large database into smaller, independent pieces (shards) spread across multiple machines — each shard holds a subset of the data.

📌 Why Sharding?

Read replicas help with reads. But what when writes bottleneck?

10M writes/day → 1 Primary DB can't keep up
Data: 100 TB → 1 server can't store it all

Sharding splits both storage AND write load.

💡 How Sharding Works

Imagine a users table with 100M rows.

Without sharding: All 100M rows on one server.

With sharding (4 shards):

Shard 0: users where userId % 4 = 0  (25M rows)
Shard 1: users where userId % 4 = 1  (25M rows)
Shard 2: users where userId % 4 = 2  (25M rows)
Shard 3: users where userId % 4 = 3  (25M rows)

🔑 Sharding Strategies

1. Hash-Based Sharding

shard = hash(shardKey) % numShards

✅ Even distribution

❌ Adding shards → massive rebalancing (use consistent hashing!)

Best for: User IDs, random keys

2. Range-Based Sharding

Shard 0: userId 1–1,000,000
Shard 1: userId 1,000,001–2,000,000
...

✅ Simple, range queries efficient

❌ Hot spots if data isn't evenly distributed (new users pile into last shard)

Best for: Time-series data (date ranges), ordered data

3. Directory-Based Sharding

[Lookup Service / Mapping Table]
userId 1234 → Shard 3
userId 5678 → Shard 1

✅ Most flexible — can move data between shards

❌ Lookup service becomes bottleneck / SPOF

Best for: When data movement between shards is needed

4. Geographic Sharding

Users in India    → Shard-India  (Mumbai)
Users in US       → Shard-US     (Virginia)
Users in Europe   → Shard-EU     (Frankfurt)

✅ Low latency for users

❌ Cross-shard queries for global reports

Best for: Multi-region products with data residency requirements

🔑 Choosing a Shard Key

The most critical decision in sharding. A bad shard key causes:

Hot spots — all traffic goes to one shard
Uneven data — one shard is 10× larger
Cross-shard joins — expensive queries

Good Shard Key Properties

Property	Why
High cardinality	Many unique values → even distribution
Low correlation	Shouldn't correlate with access patterns
Immutable	Changing it means moving data between shards
Frequently queried	Queries can be routed to one shard

Common Shard Keys

System	Shard Key
User data	`userId`
Multi-tenant SaaS	`tenantId`
Messages	`conversationId` or `userId`
Orders	`customerId` or `orderId`
Time-series	`timestamp` + `deviceId`

⚠️ Sharding Challenges

Cross-Shard Queries

-- This is easy on 1 DB:
SELECT * FROM orders JOIN users ON orders.userId = users.id

-- With sharding: users on Shard 0, orders on Shard 1 → expensive cross-shard join!

Solutions:

Denormalize data (store redundant user info in orders table)
Application-level joins (fetch from each shard, merge in code)
Co-locate related data on same shard (order and user on same shard)

Rebalancing

Adding a new shard → need to move data → expensive operation

Solution: Consistent hashing minimizes data movement

Hot Spots

Celebrity/viral content — 90% of requests go to one shard.

Solution: Key splitting — split the hot key across multiple shards with a suffix:

tweet:viral_id_0, tweet:viral_id_1, tweet:viral_id_2 ...

🏗️ Sharding Architecture

[App Server] → [Shard Router / Proxy Layer]
                    │
          ┌────────┼────────┐
       [Shard 0] [Shard 1] [Shard 2]
          │          │         │
       [Replica] [Replica] [Replica]  (each shard also has replicas!)

🆚 Sharding vs Partitioning

Term	Meaning
Sharding	Horizontal partitioning across different machines
Partitioning	Splitting data within one machine (e.g., PostgreSQL table partitions)

Start with partitioning (within one DB), then shard when you need cross-machine scale.

🎨 Diagram

The diagram shows:

Shard router receiving queries
Hash-based routing to 3 shards
Each shard with its own replica
Cross-shard join problem highlighted in red

🔑 Key Takeaways

Sharding splits both data and write load across machines
Shard key choice is irreversible — choose carefully
Start with vertical scaling → read replicas → sharding (don't jump to sharding early)
Every large database (DynamoDB, Cassandra, MongoDB) shards internally for you

🥧 314 Trillion Digits of Pi: The Software Engineering Secrets Behind y-cruncher

Gouranga Das Samrat — Thu, 11 Jun 2026 04:00:00 +0000

How a high school project became the most dominant Pi-computing benchmark in the world — and what every software engineer can learn from it.

If someone told you a single program could stress-test your CPU, RAM, and storage simultaneously, recover from hardware failures mid-computation, run for 110 days straight, and spit out 314 trillion digits of Pi at the end — you'd probably assume it was built by a team of PhDs at a national lab.

It was built by one person. It started as a high school project. And it's been setting world records since 2009.

This is y-cruncher. Let's talk about it.

What Even Is y-cruncher?

y-cruncher is a multi-threaded, SIMD-vectorized program that computes mathematical constants — Pi, e, square roots, and more — to trillions of decimal digits. It's the tool of choice for:

World record Pi computations (every record since 2009 has used it)
CPU stress testing and overclocking validation
Memory subsystem benchmarking
Hardware stability detection (it'll find flaws that Prime95 and AIDA64 miss)

As of November 2025, the current world record stands at 314 trillion digits, computed in a single uninterrupted 110-day run on a 384-core AMD EPYC server. The verification took just 4.37 hours.

Why Should a Software Engineer Care?

Fair question. You're probably not computing Pi for a living. But y-cruncher is a goldmine of fascinating engineering decisions:

It exploits SIMD instruction sets (SSE, AVX, AVX-512) at a level most production software never touches
Its checkpoint-restart system is a masterclass in fault-tolerant distributed computation
It implements custom memory allocators that outperform the OS for specific access patterns
It demonstrates how multi-socket NUMA topology wreaks havoc on parallel performance — and how to fight back
Its benchmark results expose the memory bandwidth ceiling that most workloads never hit but y-cruncher constantly runs into

In short: reading about y-cruncher will make you a better systems programmer, even if you never run it.

Getting Started: Installation in Under 2 Minutes

Windows

Download y-cruncher v0.8.7.9547b.zip from the official site
Extract and run y-cruncher.exe
You may need the MSVC redistributable if you see DLL errors

Note: Antivirus false positives are common due to the low-level SIMD code. The binary is safe — but the static-linked version was reworked specifically to reduce false positives.

Linux

Choose between two variants based on your needs:

# Static — most portable, works on nearly any distro, no TBB/NUMA binding
wget http://www.numberworld.org/y-cruncher/y-cruncher\ v0.8.7.9547-static.tar.xz
tar -xf "y-cruncher v0.8.7.9547-static.tar.xz"
cd y-cruncher_v0.8.7.9547-static
./y-cruncher

# Dynamic — full features (NUMA binding, TBB) but requires Ubuntu 24.04+ or compatible
wget http://www.numberworld.org/y-cruncher/y-cruncher\ v0.8.7.9547-dynamic.tar.xz
tar -xf "y-cruncher v0.8.7.9547-dynamic.tar.xz"
./y-cruncher

System requirements:

64-bit x86/x64 processor
Windows 8+ or any 64-bit Linux distro
RAM: as much as you can get — more is almost always better

Running Your First Benchmark

When you launch y-cruncher, you'll get a console menu. For benchmarking:

Select "Benchmark" from the main menu
Choose a size (start with 250 million or 1 billion digits — comfortable for most modern desktops)
Watch it go

What you'll see reported:

Computation mode : Ram Only
Decimal Digits   : 1,000,000,000
Hexadecimal Digits: 830,482,023

Start Date       : ...
End Date         : ...

Total Computation Time : 14.670 seconds
Total Verification Time: 10.421 seconds
Total Time             : 25.091 seconds

Tip: "Total Computation Time" is the relevant benchmark number. "Total Time" includes verification, which is a separate algorithmic pass.

What are "good" numbers?

Here's a quick reference for 1 billion digits on common hardware (lower = better):

Hardware	Time (seconds)
Ryzen 9 9950X (16C, DDR5-6000)	~14.7s
Intel Core i9-13900KS	~15.9s
Ryzen 9 7950X (16C, DDR5-5200)	~16.8s
Ryzen 9 3950X (16C, DDR4-3200)	~29.5s
Core i7-11800H (laptop, 60W)	~32.3s

If your number is significantly higher than expected for your hardware, it's usually a memory configuration issue (see below).

The Memory Bandwidth Trap: Why Your Expensive CPU Might Be Underperforming

This is one of the most practically useful things y-cruncher teaches.

y-cruncher is memory-bound. Almost completely. On every high-end desktop since ~2012, the CPU sits and waits for data. This means:

GHz doesn't matter as much as memory bandwidth
Unpopulated DIMM slots hurt you more than you think
Memory frequency matters enormously

Real benchmark showing this on a Core i9-7940X:

Memory speed	10 billion digit time
DDR4-2666	365 seconds
DDR4-3466	322 seconds

That's a ~12% speedup just from faster RAM on the same CPU.

How to maximize memory bandwidth for y-cruncher

# Checklist:
# 1. Populate ALL memory channels
#    (4-channel platform = use 4 DIMMs, not 2)

# 2. Enable XMP/EXPO in BIOS
#    Most DDR4/DDR5 kits ship at JEDEC defaults (3200/4800)
#    XMP can push to 6000+ MT/s on DDR5

# 3. On Skylake-X specifically: also overclock L3 cache
#    (L3 bandwidth is an additional bottleneck on that architecture)

# 4. Enable Large Pages (Windows)
#    Run y-cruncher as Administrator for this to work
#    Post-Spectre/Meltdown mitigations cause up to 5% overhead
#    Large pages bypass the problematic page table walk

The Engineering Marvel: Checkpoint-Restart

Here's what separates y-cruncher from just being a fast calculator.

Computing 300 trillion digits of Pi takes months. On commodity hardware. With power outages, kernel panics, memory errors, and cosmic ray bit flips all waiting to destroy your work.

y-cruncher's solution is a robust checkpoint-restart system that:

Periodically snapshots computation state to disk
Verifies checkpoints with redundancy checks (catching hardware bit errors before they propagate)
Resumes automatically after any interruption — even after software bugs in y-cruncher itself have been fixed and the computation re-started

Several world record computations have survived bugs in y-cruncher itself because the checkpoint infrastructure caught the error, allowed a fix, and resumed from the last valid state. That's some serious fault tolerance engineering.

The 314 trillion digit record in November 2025 is remarkable specifically because it was the first recent record achieved without checkpointing — a single uninterrupted 110-day run. This is described as Storage Review's third attempt; the previous two were stopped by hardware/software issues.

For the software engineers in the room: this is a production-grade distributed systems problem solved elegantly in a desktop application.

Advanced: The NUMA Problem (And Why Multi-Socket Is Hard)

If you're running y-cruncher on a workstation with two CPUs — or benchmarking cloud instances — pay attention.

On multi-socket (NUMA) systems, memory access latency and bandwidth are asymmetric. Core 0 on Socket 0 reaches Socket 0's RAM in ~80ns. It reaches Socket 1's RAM in ~140ns. If your threads are spread across both sockets but chasing the same data, you'll hit contention that tanks throughput.

y-cruncher's documentation is explicit about this:

Benchmark numbers on multi-socket machines "may not be entirely representative of what the hardware is capable of"
The Push Pool vs Cilk Plus scheduler choice matters for machines with >64 cores
Node-interleaving in the BIOS should be disabled on Windows systems with >64 logical cores (otherwise you get imbalanced processor groups)

The load imbalance symptoms to watch for:

Core count is not a power of two
Cores are heterogeneous (hybrid architectures like Intel's P+E core designs)
Background processes stealing cycles from any single thread

Using y-cruncher for Stress Testing (The Real Killer App)

Many overclockers and hardware enthusiasts use y-cruncher specifically because it's uniquely good at exposing instability:

It simultaneously maxes out CPU computation AND the entire memory subsystem. Most stress tests only hit one or the other. y-cruncher hits both at the same time.

The telltale error you'll see on unstable hardware:

Redundancy Check Failed: Coefficient is too large

This means the two independent algorithmic passes (compute + verify) produced different results — which means either the CPU computed something wrong, or memory delivered corrupted data.

If you see this on a machine you thought was stable: don't ignore it. This is y-cruncher doing exactly what it's designed to do.

Common causes:

RAM running at XMP/EXPO speeds without sufficient voltage
CPU overclocked too aggressively (especially with AVX offsets not set)
Thermal throttling corrupting in-flight computation
Subtimings too tight on the memory controller

Understanding the Algorithms (For the Curious)

y-cruncher uses two independent algorithms for most constants:

Computation pass: Chudnovsky algorithm for Pi (exponentially converging series). Each term adds ~14.18 digits of Pi. The challenge is computing this in arbitrary precision — which requires implementing arithmetic on numbers with trillions of digits.

Verification pass: A different formula (e.g., Ramanujan's formula, or Bailey-Borwein-Plouffe variants) to independently confirm the result. If both passes agree to the last digit, the result is almost certainly correct.

The interesting engineering is in the big number arithmetic:

Uses Number Theoretic Transforms (NTTs) — the modular arithmetic equivalent of FFTs — for multiplication
Exploits SIMD vector units (AVX-512 on modern hardware) to parallelize the transform butterflies
Implements cache-oblivious algorithms for better memory access patterns during the transform

The result: multiplication of two N-digit numbers in O(N log N) time instead of O(N²). At a trillion digits, this difference is the gap between "computationally feasible" and "computationally impossible."

Practical Takeaways for Software Engineers

Whether you run y-cruncher or never touch it, here's what to take away:

1. Memory bandwidth is often your real bottleneck. Profile for it. Don't just assume your algorithm is CPU-bound.

2. Fault tolerance is a first-class feature. The world record wouldn't exist without checkpoint-restart. Think about what your long-running jobs do when a node dies.

3. NUMA topology changes everything in parallel code. Thread affinity and memory locality matter more than raw core count on multi-socket systems.

4. SIMD is still a performance multiplier worth understanding. A 4× speedup from AVX-2 or 8× from AVX-512 is not unusual for data-parallel numerical code. Compilers help, but hand-tuning helps more.

5. Stress test with something that actually stresses. y-cruncher's simultaneous CPU + memory load finds problems that single-threaded or DRAM-only tests miss entirely.

Where to Go From Here

Download y-cruncher: numberworld.org/y-cruncher
GitHub mirror: Available for HTTPS downloads (linked from the main site)
Benchmarks leaderboard: Rankings from 25 million to 1 trillion digits are published on the site
Advanced docs: The site has deep documentation on multi-threading internals, memory allocation strategies, and swap mode configuration
Mersenneforum subforum: For discussion with the community doing record-level runs

The fact that a program started as a high school project now drives the world's most demanding computational records — and teaches systems programmers lessons about memory bandwidth, fault tolerance, NUMA, and SIMD — is genuinely inspiring.

Go run it. Break your overclock. Then fix it and run it again.

pkg.go.dev Finally Has an Official API — No More Web Scraping

Gouranga Das Samrat — Wed, 10 Jun 2026 04:00:00 +0000

If you've ever built a Go tool that needed package metadata — documentation, versions, symbols, import counts — you already know the pain. You were either scraping the pkg.go.dev HTML (fragile, bad, and you knew it), or you were guessing from local filesystem data and hoping for the best.

The Go team just shipped a real fix for this: an official pkg.go.dev API.

Let's look at what it actually does.

What's Available

The API lives under /v1beta and covers the main things you'd actually need:

Endpoint	What it gives you
`/v1beta/package/{path}`	Package metadata
`/v1beta/module/{path}`	Module metadata
`/v1beta/versions/{path}`	All versions of a module
`/v1beta/packages/{path}`	All packages in a module
`/v1beta/search?q={query}`	Search results
`/v1beta/symbols/{path}`	Exported symbols
`/v1beta/imported-by/{path}`	What imports this package
`/v1beta/vulns/{path}`	Known vulnerabilities

The v1beta label is honest — it's not finalized yet. But the team has committed to moving toward a stable v1 after a feedback period, and they're promising backward compatibility going forward.

Quick Start: Hit It With curl

No auth, no setup. Just GET requests:

curl https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp | jq .

Response:

{
  "modulePath": "github.com/google/go-cmp",
  "version": "v0.7.0",
  "isLatest": true,
  "isStandardLibrary": false,
  "goos": "all",
  "goarch": "all",
  "path": "github.com/google/go-cmp/cmp",
  "name": "cmp",
  "synopsis": "Package cmp determines equality of values.",
  "isRedistributable": true
}

You can pin a specific version:

curl "https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp?version=v0.6.0" | jq .

Or use master / main branch names, which resolve automatically to their pseudo-version:

curl -s "https://pkg.go.dev/v1beta/package/github.com/google/go-cmp/cmp?version=master" | jq '{path, version}'
# {
#   "path": "github.com/google/go-cmp/cmp",
#   "version": "v0.7.1-0.20260310220054-34c9473539b8"
# }

One Gotcha: Module Paths Must Be Unambiguous

This tripped me up when I first read the docs. The API follows a "precision over convenience" rule that differs from the web UI.

On the website, if you type example.com/a/b/c, it resolves to the longest matching module path automatically. The API won't do that. If example.com/a/b/c could live in either example.com/a or example.com/a/b, the API returns an error and asks you to be more specific.

Makes sense for programmatic use — you don't want silent resolution surprises in a tool. Just something to plan for when you're building integrations.

The Reference CLI: `pkgsite-cli`

The Go team also shipped a reference client you can install and start using immediately:

go install golang.org/x/pkgsite/cmd/internal/pkgsite-cli@latest

Search for packages:

pkgsite-cli search "uuid"
# github.com/google/uuid
#   Module:   github.com/google/uuid@v1.6.0
#   Synopsis: Package uuid generates and inspects UUIDs.

Inspect a package:

pkgsite-cli package github.com/google/go-cmp/cmp

See what imports a package:

pkgsite-cli package --imported-by github.com/google/go-cmp/cmp

List exported symbols:

pkgsite-cli package --symbols github.com/google/go-cmp/cmp

List all versions of a module:

pkgsite-cli module -versions github.com/google/go-cmp

Worth noting: the CLI interface is explicitly marked as unstable — it's a reference implementation, not a finished product. Use it to understand the API, not as a dependency in scripts you care about.

Why This Matters Now

The "years of community feedback" line in the announcement is underselling it. Go tooling has had a real data access gap for a long time. Custom linters, documentation generators, dependency analyzers, IDE plugins — all of them were either scraping or going without.

The announcement also mentions AI-assisted coding tools specifically, and that's probably the real driver here. Tools that reason about your dependencies need structured, reliable data about packages. Scraping doesn't cut it when you want a language server to tell you something accurate about a module it's never seen before.

An OpenAPI spec is published too, so generating clients in any language is straightforward.

What I'd Use This For

A few things come to mind immediately:

Dependency audits — pull vulnerability data via /v1beta/vulns/{path} for every module in your go.sum without spinning up a full govulncheck run.

Import graph tooling — the /v1beta/imported-by endpoint makes it practical to build tools that understand downstream impact of an API change.

Documentation bots — fetch synopsis and symbol data for packages your team uses, feed it wherever you need it.

Version tracking — watch specific modules for new releases without polling GitHub.

The State of It

It's a v1beta. The endpoints work, the data is good, and the team is clearly committed to making this a real stable API. But I wouldn't bet a production pipeline on the exact response shape staying identical until v1 lands.

For internal tooling and experiments? Use it today. For anything you're shipping to other people? Keep an eye on the issue tracker and wait for v1.

Go give it a curl. The full API spec and OpenAPI definition are live now.

Feedback and bug reports go to the pkgsite issue tracker. The team specifically asked for community feedback before the v1 freeze, so this is a good time to poke at edge cases.