DEV Community: Gouranga Das Samrat

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.

Database Scaling

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

One-liner: Databases are the hardest part to scale — the strategy is: vertical first → read replicas → caching → sharding.

📌 Scaling Ladder

Stage 1: Single DB (< 10K users)
Stage 2: Separate DB server from app server
Stage 3: Add caching (Redis) — reduce DB reads by 80%
Stage 4: Read Replicas — distribute read traffic
Stage 5: Database Sharding — distribute write traffic + data
Stage 6: CQRS + Event Sourcing (advanced)

Never jump to Stage 5 without exhausting Stages 3 and 4.

📊 The Read/Write Split

Most web apps: ~90% reads, ~10% writes.

Optimize reads first:
  → Add Redis cache (most impactful)
  → Add read replicas
  → Add CDN for static data

Only then optimize writes:
  → Sharding
  → Async writes (queue + batch)

🗃️ Connection Pooling

Never create a new DB connection per request. Use a pool.

// pg (Node.js PostgreSQL)
const pool = new Pool({
  max: 20, // max 20 connections
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

const result = await pool.query("SELECT * FROM users WHERE id = $1", [id]);

Without pooling: 1000 req/sec = 1000 new connections = DB crashes.

Consistent Hashing

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

One-liner: A hashing technique that minimizes the number of keys that need to be remapped when servers are added or removed.

📌 The Problem It Solves

Imagine you have 3 cache servers and you distribute keys using:

server = hash(key) % N  (N = number of servers)

Works fine until N changes:

N=3: hash("user123") % 3 = 1 → Server 1
N=4: hash("user123") % 4 = 3 → Server 3  ← DIFFERENT!

When you add or remove a server, almost ALL keys remap → massive cache miss storm → database gets hammered.

💡 The Solution: Consistent Hashing

How It Works

Map both servers and keys onto the same circular hash ring (0 to 2³²)
Each key is assigned to the first server clockwise from its position
Adding/removing a server only affects adjacent keys

         0
      /     \
  S3         S1
    \       /
         S2
        360°

Key K1 → clockwise → lands on S1
Key K2 → clockwise → lands on S2

Adding a Server

Before:  K1→S1, K2→S1, K3→S2, K4→S3
Add S4 between S1 and S2:
After:   K1→S1, K2→S4, K3→S2, K4→S3  ← Only K2 moved!

Removing a Server

Before: K1→S1, K2→S2, K3→S2, K4→S3
Remove S2:
After:  K1→S1, K2→S3, K3→S3, K4→S3  ← K2 and K3 moved to next server

⚖️ Problem: Uneven Distribution

With few servers, the ring can be unbalanced:

S1 handles 60% of keyspace
S2 handles 30% of keyspace
S3 handles 10% of keyspace

Solution: Virtual Nodes (VNodes)

Instead of 1 point per server, use many virtual points:

S1 → S1_1, S1_2, S1_3 ... S1_100  (spread around ring)
S2 → S2_1, S2_2, S2_3 ... S2_100
S3 → S3_1, S3_2, S3_3 ... S3_100

Result: Much more even distribution. Each physical server maps to ~N/total keys.

🏗️ Implementation Sketch

class ConsistentHash {
  constructor(replicas = 100) {
    this.replicas = replicas; // virtual nodes per server
    this.ring = new Map(); // hash → serverName
    this.sortedKeys = [];
  }

  addServer(server) {
    for (let i = 0; i < this.replicas; i++) {
      const hash = md5(`${server}:${i}`);
      this.ring.set(hash, server);
      this.sortedKeys.push(hash);
    }
    this.sortedKeys.sort();
  }

  getServer(key) {
    const hash = md5(key);
    // Find first server clockwise
    for (const k of this.sortedKeys) {
      if (k >= hash) return this.ring.get(k);
    }
    return this.ring.get(this.sortedKeys[0]); // wrap around
  }
}

📊 Consistent Hashing vs Modulo Hashing

Dimension	Modulo Hashing	Consistent Hashing
Keys remapped on resize	~100%	~1/N
Uneven distribution	Even	Possible (fix with VNodes)
Complexity	O(1)	O(log N) per lookup
Use case	Fixed set of servers	Dynamic server pool

🌍 Real-World Use Cases

System	How it's used
Cassandra	Partitions data across nodes
DynamoDB	Key-based partitioning
Memcached/Redis Cluster	Distributing cache keys
Nginx	Consistent upstream selection
CDN	Routing requests to edge nodes
Kafka	Partition assignment

🎨 Excalidraw Diagram

The diagram shows:

The hash ring as a circle
Server nodes placed on the ring
Keys mapped to nearest server clockwise
Virtual nodes distributed around the ring
Before/after adding a server (minimal key movement)

🔑 Key Takeaways

Modulo hashing causes thundering herd on any server change
Consistent hashing limits disruption to ~1/N keys per change
Virtual nodes (VNodes) solve the uneven distribution problem
This is used everywhere in distributed databases and caches

Back of Envelope Calculations

Gouranga Das Samrat — Fri, 05 Jun 2026 02:00:00 +0000

One-liner: Rough estimates done quickly to understand the scale of a system before designing it. They tell you what tier of infrastructure you need.

📌 Why This Matters

Before designing ANY system, you need to know:

How many users will use it?
How many requests per second?
How much storage do we need?
How much bandwidth is required?

These estimates shape every architectural decision.

🔢 Numbers Every Engineer Should Know

Time

Unit	Value
1 millisecond	10⁻³ seconds
1 microsecond	10⁻⁶ seconds
1 nanosecond	10⁻⁹ seconds
Seconds in a day	~86,400 ≈ 10⁵
Seconds in a month	~2.5M ≈ 2.5 × 10⁶
Seconds in a year	~31.5M ≈ 3 × 10⁷

Latency Numbers (Approximate)

Operation	Latency
L1 cache reference	1 ns
L2 cache reference	4 ns
RAM reference	100 ns
SSD random read	150 µs
HDD seek	10 ms
Network: same datacenter	500 µs
Network: cross-region (US→EU)	150 ms
Network: cross-continent	200–300 ms

Storage Units

Unit	Size
1 KB	10³ bytes
1 MB	10⁶ bytes
1 GB	10⁹ bytes
1 TB	10¹² bytes
1 PB	10¹⁵ bytes

📐 The Estimation Framework

Step 1: DAU → QPS

Daily Active Users (DAU)    = 10 million
Avg requests per user/day   = 10
Total daily requests        = 100 million

QPS = 100M / 86,400 ≈ 1,200 req/sec
Peak QPS (2-3x average)     ≈ 3,000 req/sec

Step 2: Storage

New posts per day    = 1M
Avg post size        = 1 KB (text) + 500 KB (image)
Daily storage        = 1M × 501 KB ≈ 500 GB/day
Yearly storage       = 500 GB × 365 ≈ 180 TB/year
5-year storage       ≈ 1 PB

Step 3: Bandwidth

Reads per second     = 100K req/sec
Avg response size    = 10 KB
Outbound bandwidth   = 100K × 10 KB = 1 GB/sec

🔬 Real Example: Design Twitter

Assumptions

300M DAU
Each user reads 10 tweets/day
Each user writes 1 tweet/week ≈ 0.14 tweets/day
Avg tweet: 280 chars = 280 bytes ≈ 300 bytes
10% of tweets have an image (~200 KB)

Read QPS

300M users × 10 reads/day = 3B reads/day
QPS = 3B / 86,400 ≈ 35,000 reads/sec
Peak QPS ≈ 100,000 reads/sec

Write QPS

300M × 0.14 = 42M tweets/day
QPS = 42M / 86,400 ≈ 500 writes/sec

Storage per day

Text: 42M × 300 bytes = 12.6 GB
Images: 42M × 10% × 200 KB = 840 GB
Total: ~850 GB/day ≈ 310 TB/year

Bandwidth

Read traffic: 35K req/sec × 1 KB/response ≈ 35 MB/sec = ~300 Gbps

🔬 Real Example: Design WhatsApp

Assumptions

2B DAU
Each user sends 20 messages/day
Avg message: 100 bytes
30% are media messages (500 KB avg)

QPS

2B × 20 = 40B messages/day
QPS = 40B / 86,400 ≈ 460,000 msg/sec
Peak QPS ≈ 1M msg/sec

Storage per day

Text: 40B × 100B = 4 TB
Media: 40B × 30% × 500 KB = 6 PB/day (too high → add retention/compression policy)

💡 Tips for Interviews

Always ask before estimating — "Should I assume 10M or 100M users?"
Round aggressively — 86,400 → 10⁵, 3.14 → 3
Peak = 2-3× average (or 5-10× for viral/event-based systems)
Show your math — interviewers care about the process, not the exact number
Derive storage needs from estimates — don't pull numbers from thin air
1 char = 1 byte (ASCII), 1 char = 2-4 bytes (Unicode)

📋 Estimation Cheat Sheet

1K users  → Single server fine
10K users → Need to think about DB separation
100K users → Load balancer, read replicas
1M users  → Caching layer, CDN, sharding
10M users → Distributed systems, microservices
100M+     → You work at a FAANG (or interview there)

🔑 Key Takeaways

Back-of-envelope is about order of magnitude, not precision
Know the key numbers cold: bytes, seconds in a day, latency tiers
Always separate read QPS from write QPS — they're usually very different
Storage estimations reveal whether you need sharding/archival early

TypeScript 7.0 Beta is Here — and It's Rewritten in Go. Here's What Actually Changed.

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

I've been watching the TypeScript Go port news since it first leaked, and I'll be honest — when they said "10x faster," I was ready to call marketing spin. Then I ran it on a real codebase.

It's fast. Like, uncomfortably fast. The kind of fast where you assume something must be broken.

TypeScript 7.0 Beta dropped on April 21st, and it's not your usual TypeScript release. This isn't "we added a few new types and fixed some edge cases." The entire compiler was ported from TypeScript (the language) to Go — and then they're calling the result TypeScript 7.0.

Let me break down what this actually means for you.

Wait, Why Go?

First question everyone asks. Why not Rust? Why not WASM?

The honest answer: speed of porting, not peak performance. Go's concurrency model and memory layout happened to align well with how the existing TypeScript compiler was structured. A Rust rewrite would've taken years and needed a ground-up redesign. The Go port took roughly a year, and it's architecturally identical to TypeScript 6.0's type-checking logic — same semantics, same results.

Pragmatic call. I think it was the right one.

How to Try It Right Now

npm install -D @typescript/native-preview@beta

Then run tsgo instead of tsc:

npx tsgo --version
# Version 7.0.0-beta

Note: the package is @typescript/native-preview for now. The stable release will eventually ship as the regular typescript package with the normal tsc command.

For VS Code, grab the TypeScript Native Preview extension. It's not a rough prototype — teams at Bloomberg, Figma, Slack, Google, and others have been running pre-release builds for over a year. It's been solid for months.

The Performance Is the Main Event

The Go rewrite isn't just a compiler curiosity. It unlocks parallelization that the old JS runtime couldn't do:

--checkers controls how many type-checking workers run in parallel (default: 4). Bigger codebases on beefy machines can push this higher. CI runners with limited cores should drop it down.

--builders controls parallel project reference builds — a big deal for monorepos. Combined with --checkers, it multiplies. --checkers 4 --builders 4 = up to 16 type-checkers running simultaneously.

--singleThreaded if you need to debug or benchmark against TypeScript 6 without parallelism noise.

The team reports ~10x speedups on large codebases. Based on what early adopters are saying publicly, that tracks.

Running 7.0 Alongside 6.0 (Without Chaos)

This part tripped me up at first. Here's the clean way to handle it.

There's a new compatibility package: @typescript/typescript6. It exposes a tsc6 entry point, so you can run both without naming collisions.

If you use tools like typescript-eslint that peer-depend on typescript directly, do this in your package.json:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0"
  }
}

This aliases the typescript package to 6.0, so your existing tooling stays happy while you experiment with tsgo on the side.

Breaking Changes — The Ones That Will Actually Bite You

TypeScript 7.0 adopts 6.0's defaults as hard requirements. A lot of these were opt-in before. Now they're just on, with no escape hatch.

Defaults that changed:

strict is true by default
module defaults to esnext
noUncheckedSideEffectImports is true
types defaults to [] — your @types/node won't be picked up automatically anymore

The rootDir change is subtle but will catch you:

If your tsconfig.json sits outside your src/ folder (pretty common), you need to add this:

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

The types change will also catch you:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

List every @types package your project needs explicitly. No more implicit globals from everything in your node_modules/@types.

Things that are just gone:

target: es5 — not supported
moduleResolution: node / node10 — use nodenext or bundler
module: amd, umd, systemjs, none — gone
baseUrl — use paths relative to the project root instead
downlevelIteration — gone

If you're still on any of these, migrating to TypeScript 6.0 first will make the 7.0 transition cleaner.

JavaScript Support Got a Full Rethink

This one flew under my radar until I read the details. TypeScript 7.0 rewrites how .js files are handled — moving away from Closure-style JSDoc support toward patterns consistent with .ts files.

Key changes:

@enum is no longer special — you need @typedef instead
@class on a function doesn't make it a constructor anymore — use a class declaration
Closure-style function syntax like function(string): void is dropped — use (s: string) => void
values can't be used where types are expected — use typeof someValue

If you have a pure-JS codebase that relied on TypeScript's JSDoc inference, check the CHANGES.md before upgrading.

What's Still Missing

The beta label is real, but it's not hiding a disaster — it's flagging a few known gaps:

No stable programmatic API yet (that's TypeScript 7.1 at earliest)
--watch mode is less efficient than it'll eventually be
Some VS Code features are still coming: semantics-enhanced highlighting, more granular import commands
Declaration file emit from .js files is still being finished

If you depend on the TypeScript compiler API for custom tooling, wait for 7.1. For everything else — type-checking in CI, editor experience, build times — 7.0 Beta is ready.

My Take

The Go port is a genuinely impressive engineering decision. Not the most glamorous language choice, not the theoretical peak, but it shipped in about a year and already works on multi-million line codebases.

The breaking changes are real, but most of them were coming anyway. TypeScript 6.0 gave everyone a year to see them coming. If you've been keeping up with releases, 7.0 should feel like a minor migration with a huge performance payoff.

If you haven't touched your tsconfig.json in two years and still have moduleResolution: node in there... you have some cleanup to do. But that cleanup was overdue regardless of whether TypeScript 7 existed.

Try it today:

npm install -D @typescript/native-preview@beta
npx tsgo --version

Run it on something real and let the speed be someone else's excuse to finally upgrade the old config.

Found issues? The team wants feedback at the microsoft/typescript-go issue tracker — not the main TypeScript repo. That distinction matters during the beta.

Single Server Setup

Gouranga Das Samrat — Wed, 03 Jun 2026 02:00:00 +0000

One-liner: The simplest possible architecture — one machine running everything. Great for starting out, but a single point of failure.

📌 What Is It?

[Browser] ─── HTTP ──► [Single Server]
                          ├── Web Server (Nginx/Apache)
                          ├── App Code (Node/Python/Java)
                          └── Database (MySQL/PostgreSQL)

One machine handles everything: web serving, business logic, database.

✅ When It's Fine

Prototype / MVP stage
<1,000 daily users
Internal tool / side project
Learning / development

❌ Problems

Problem	Impact
SPOF	Server dies → everything down
No scaling	Can't add more machines
Resource contention	App and DB fight for CPU/RAM
Hard to update	Any deploy = full downtime

🚀 First Step: Separate App & DB

[Browser] → [App Server] → [DB Server]

Now you can scale each independently.