Blog

The stuff they don't
teach you at work.

Real architecture decisions. Real trade-offs. Written by engineers who've shipped at scale — not content marketers.

Three scheduler nodes — only the leader triggers jobs

  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
  │  Scheduler  │     │  Scheduler  │     │  Scheduler  │
  │   Node A    │     │   Node B    │     │   Node C    │
  │  ★ LEADER  │     │  (standby)  │     │  (standby)  │
  └──────┬──────┘     └──────┬──────┘     └──────┬──────┘
         │                   │                   │
         │    heartbeat      │    heartbeat      │
         └──────────────────▶│◀──────────────────┘
                             ▼
                    ┌─────────────────┐
                    │  Distributed    │
                    │  Lock Store     │
                    │  (Redis/etcd)   │
                    └─────────────────┘

  Node A holds lock with TTL=30s, renews every 10s.
  If Node A dies, lock expires → Node B or C acquires it.
SYS
System Design13 min read

Building a Distributed Job Scheduler

Why single-node job schedulers silently fail in production, and how to build a distributed scheduler with leader election, task deduplication, and failure recovery.

Akhil Sharma

Akhil Sharma

April 4, 2026

↗
0° / 360°
                          │
           ╔══════════════╧══════════════╗
           ║                             ║
    330° ──║── Server C         Server A ──║── 30°
           ║       │                 │   ║
           ║       │   Key "user:42" │   ║
           ║       │   hashes to 10° │   ║
           ║       │   walks ──────▶ │   ║
           ║       │   clockwise to  │   ║
           ║       │   Server A  ────┘   ║
           ║       │                     ║
    150° ──║── Server B                  ║
           ║                             ║
           ╚═════════════════════════════╝

   Key at 10° → nearest clockwise server → Server A (30°) ✓
SYS
System Design12 min read

Consistent Hashing in Practice

Why modulo hashing silently nukes your cache every time you scale, and how consistent hashing solves the rebalancing problem that takes down databases.

Consistent HashingDistributed SystemsCaching
Akhil SharmaAkhil Sharma
Apr 3
Your System                                    Customer Endpoint
─────────────                                  ─────────────────
  Event occurs
      │
      ▼
 ┌──────────┐   Write first,
 │ Postgres │   attempt second.       ┌─────────────────────────┐
 │ (events) │   If we crash here,     │                         │
 └────┬─────┘   we can recover.       │  https://api.acme.com   │
      │                               │  /webhooks              │
      ▼                               │                         │
 ┌──────────┐                         └────────────┬────────────┘
 │  Worker  │──── POST /webhooks ─────────────────▶│ 200 OK ✓
 │  polls   │                                       │
 │  table   │──── POST /webhooks ─────────────────▶│ 503 ✗
 └────┬─────┘              │                        └────────────
      │                    │ failure
      │         ┌──────────▼──────────┐
      │         │  Schedule retry     │
      │         │  (backoff + jitter) │
SYS
System Design13 min read

Designing a Reliable Webhook Delivery System

How to build a webhook delivery system that handles retries, dead letter queues, and delivery guarantees without hammering failing endpoints or losing events.

WebhooksDistributed SystemsReliability
Akhil SharmaAkhil Sharma
Apr 2
Phase 1: Proxy intercepts all traffic
┌────────┐    ┌───────┐    ┌────────────┐
│ Client │───▶│ Proxy │───▶│   Legacy   │
│        │    │       │    │   System   │
└────────┘    └───────┘    └────────────┘

Phase 2: Some routes go to new system
┌────────┐    ┌───────┐    ┌────────────┐
│ Client │───▶│ Proxy │───▶│   Legacy   │  (most routes)
│        │    │       │    └────────────┘
└────────┘    │       │    ┌────────────┐
              │       │───▶│    New     │  (/api/users)
              └───────┘    │   System   │
                           └────────────┘

Phase 3: Most routes migrated
┌────────┐    ┌───────┐    ┌────────────┐
│ Client │───▶│ Proxy │───▶│   Legacy   │  (few remaining)
│        │    │       │    └────────────┘
└────────┘    │       │    ┌────────────┐
ARCH
Architecture10 min read

The Strangler Fig Pattern: Migrating Legacy Systems Incrementally

Implementing the strangler fig pattern for legacy migration with request routing, data synchronization, feature parity verification, and a realistic migration timeline.

MigrationLegacy SystemsStrangler Fig
Akhil SharmaAkhil Sharma
Mar 26
┌─────────────────────────────────┐
│  Layer 1: Deterministic Checks  │  ← Fast, cheap, CI-friendly
│  (Format, schema, constraints)  │
├─────────────────────────────────┤
│  Layer 2: LLM-as-Judge          │  ← Moderate cost, scalable
│  (Quality, relevance, safety)   │
├─────────────────────────────────┤
│  Layer 3: Human Review          │  ← Expensive, ground truth
│  (Sample-based, weekly cadence) │
└─────────────────────────────────┘
AI
AI Engineering10 min read

Building Reliable LLM Evaluation Pipelines

How to evaluate LLM outputs systematically with automated metrics, LLM-as-judge, human review, and CI/CD integration for prompt regression testing.

EvaluationLLMTesting
Akhil SharmaAkhil Sharma
Mar 25
Client ──── POST /payments ────▶ Server (processes payment ✓)
Client ◄──── 201 Created ─────── Server
                    ↑
                  TIMEOUT (response lost)

![The retry that creates a duplicate — ACK lost, client retries, double charge](/assets/excalidraw-png/idempotency-distributed-systems/id-retry-duplicate.png)

Client ──── POST /payments ────▶ Server (processes payment again ✗ DUPLICATE)
Client ◄──── 201 Created ─────── Server
SYS
System Design10 min read

Idempotency in Distributed Systems: Patterns and Implementation

How to implement idempotency using idempotency keys, database constraints, and optimistic locking — with lessons from Stripe's approach.

IdempotencyDistributed SystemsAPI Design
Akhil SharmaAkhil Sharma
Mar 22
┌──────────────────────┐
                    │    Data Sources      │
                    │ (Events, Logs, APIs) │
                    └──────────┬───────────┘
                               │
                    ┌──────────▼───────────┐
                    │    Message Broker     │
                    │      (Kafka)          │
                    └──────┬───────┬────────┘
                           │       │
              ┌────────────▼┐     ┌▼────────────┐
              │ Batch Layer │     │ Speed Layer  │
              │ (Spark)     │     │(Kafka Streams│
              │             │     │ or Flink)    │
              │ Runs hourly │     │ Real-time    │
              │ Full recomp │     │ Approximate  │
              └──────┬──────┘     └──────┬───────┘
                     │                    │
              ┌──────▼──────┐     ┌──────▼───────┐
              │ Batch Views │     │ Real-time    │
ARCH
Architecture11 min read

Designing Data Pipeline Architecture for Real-Time Analytics

Real-time data pipeline design covering Lambda vs Kappa architecture, stream processing with Kafka Streams and Flink, and handling late-arriving data.

Data PipelinesStreamingAnalytics
Akhil SharmaAkhil Sharma
Mar 18
Kafka           RabbitMQ         NATS
Paradigm:           Log             Queue            Pub/Sub
Data model:         Append-only     Transient        Fire-and-forget
                    partitioned     (or durable)     (or JetStream)
                    log             queue            stream
```

## Feature Comparison

| Feature | Kafka | RabbitMQ | NATS (JetStream) |
|---------|-------|----------|-------------------|
| Ordering | Per-partition | Per-queue | Per-stream/subject |
| Delivery | At-least-once, exactly-once | At-least-once, at-most-once | At-least-once, exactly-once |
| Message retention | Time/size-based (days-weeks) | Until consumed | Time/size-based |
| Consumer groups | Yes (offset-based) | Yes (competing consumers) | Yes (pull/push) |
| Replay | Yes (seek to offset) | No (unless dead-lettered) | Yes (seek to sequence) |
| Routing | Topic + partition key | Exchanges, bindings, routing keys | Subject hierarchy, wildcards |
| Protocol | Custom binary | AMQP 0.9.1, MQTT, STOMP | NATS protocol, WebSocket |
| Backpressure | Consumer controls pace | Prefetch count | Pull-based, flow control |
SYS
System Design10 min read

Choosing Between Kafka, RabbitMQ, and NATS: A Decision Framework

A practical comparison of Kafka, RabbitMQ, and NATS covering ordering, delivery semantics, throughput, operational complexity, and use case fit.

KafkaRabbitMQNATS
Akhil SharmaAkhil Sharma
Mar 16
┌─────────────────────────────────────────────┐
│  Application-Level Cache                     │
│  (Exact match, semantic similarity)          │
├─────────────────────────────────────────────┤
│  Provider-Level Prefix Cache                 │
│  (Anthropic, OpenAI automatic caching)       │
├─────────────────────────────────────────────┤
│  Infrastructure-Level KV Cache               │
│  (vLLM prefix caching, PagedAttention)       │
└─────────────────────────────────────────────┘
AI
AI Engineering9 min read

Prompt Caching Strategies That Cut Your LLM Costs in Half

Practical caching strategies for LLM applications — from exact match to semantic similarity caching to provider-level prefix caching — with real cost/latency numbers.

CachingLLMCost Optimization
Akhil SharmaAkhil Sharma
Mar 14
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # At most 1 extra pod during rollout
      maxUnavailable: 0  # Never reduce below desired count
  template:
    spec:
      containers:
        - name: order-service
          image: order-service:v2.1.0
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
ARCH
Architecture10 min read

Zero-Downtime Deployments: Blue-Green, Canary, and Rolling Strategies

Deployment strategies for zero downtime with Kubernetes examples, database migration patterns, feature flags, and rollback procedures.

DeploymentsCI/CDKubernetes
Akhil SharmaAkhil Sharma
Mar 9
┌─────────┐    ┌─────────┐    ┌─────────┐
│  Logs   │    │ Metrics │    │ Traces  │
│         │    │         │    │         │
│ What    │    │ How much│    │ Why     │
│ happened│    │ & how   │    │ & where │
│         │    │ fast    │    │         │
└────┬────┘    └────┬────┘    └────┬────┘
     │              │              │
     └──────────────┼──────────────┘
                    │
              Correlation IDs
              (trace_id, span_id)
SYS
System Design10 min read

Distributed Tracing and Observability at Scale

Building observability with OpenTelemetry — trace propagation, span design, sampling strategies, and practical instrumentation patterns for distributed systems.

ObservabilityTracingOpenTelemetry
Akhil SharmaAkhil Sharma
Mar 6
// python
import json
from openai import OpenAI

client = OpenAI()

def generate_training_queries(document_chunks: list[str], n_queries_per_chunk: int = 3) -> list[dict]:
    training_pairs = []

    for chunk in document_chunks:
        response = client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{
                "role": "system",
                "content": "Generate realistic search queries that a user would type "
                           "to find this specific document. Vary the query style: "
                           "some keyword-based, some natural language questions, "
                           "some using domain jargon. Return as JSON array of strings.",
            }, {
AI
AI Engineering11 min read

Fine-Tuning Embedding Models for Domain-Specific Retrieval

When and how to fine-tune embedding models with hard negatives, contrastive loss, and practical evaluation — with before/after retrieval benchmarks.

EmbeddingsFine-TuningRetrieval
Akhil SharmaAkhil Sharma
Mar 3
Without mesh:
┌──────────┐          ┌──────────┐
│ Service A │───HTTP──▶│ Service B │
└──────────┘          └──────────┘

With mesh (sidecar model):
┌──────────────────┐          ┌──────────────────┐
│ ┌──────────┐     │          │     ┌──────────┐ │
│ │ Service A│     │          │     │ Service B│ │
│ └────┬─────┘     │          │     └────▲─────┘ │
│      │           │          │          │       │
│ ┌────▼─────┐     │          │     ┌────┴─────┐ │
│ │  Envoy   │─────┼──mTLS───┼────▶│  Envoy   │ │
│ │  Proxy   │     │          │     │  Proxy   │ │
│ └──────────┘     │          │     └──────────┘ │
└──────────────────┘          └──────────────────┘
ARCH
Architecture10 min read

Service Mesh Evaluation: Istio, Linkerd, and When You Don't Need One

Comparing Istio and Linkerd service meshes — sidecar overhead, mTLS, traffic management, and criteria for when a mesh adds more complexity than value.

Service MeshIstioLinkerd
Akhil SharmaAkhil Sharma
Mar 1
Without pooler:                     With pooler:
App (50 instances × 20 conn)       App (50 instances × 20 conn)
= 1000 PostgreSQL connections      = 1000 app connections
                                   → PgBouncer (50 PG connections)
                                   = 50 PostgreSQL connections
SYS
System Design9 min read

Database Connection Pooling: PgBouncer, PgPool, and Beyond

A deep dive into connection pooling modes, pool sizing formulas, PgBouncer vs PgPool-II architecture, and the failure modes you'll hit under load.

PostgreSQLConnection PoolingPerformance
Akhil SharmaAkhil Sharma
Feb 27
┌──────────────────┐    ┌──────────────────┐
│  Catalog Context │    │ Inventory Context │
│                  │    │                   │
│  Product:        │    │  Product:         │
│  - name          │    │  - sku            │
│  - description   │    │  - warehouse_id   │
│  - images[]      │    │  - quantity       │
│  - categories[]  │    │  - reorder_point  │
│                  │    │                   │
└──────────────────┘    └──────────────────┘
      Different models, same word "Product"
ARCH
Architecture10 min read

Domain-Driven Design: Getting Bounded Contexts Right

Practical bounded context design with context mapping patterns, event storming for boundary identification, and real domain examples from e-commerce and fintech.

DDDBounded ContextsDomain Modeling
Akhil SharmaAkhil Sharma
Feb 23
from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph.message import add_messages

class DocumentProcessingState(TypedDict):
    # Messages accumulate via the add_messages reducer
    messages: Annotated[list, add_messages]
    # Document being processed
    document: str
    # Extracted sections
    sections: list[dict]
    # Quality score from review step
    quality_score: float
    # Whether human approval is needed
    needs_approval: bool
    # Final output
    output: str | None
```

Key design principle: **state fields should represent data, not control flow.** Don't add a `current_step` field — that's what the graph edges handle. Don't add a `should_retry` boolean — use a conditional edge that checks the quality score.
AI
AI Engineering10 min read

Designing Complex AI Workflows with LangGraph

How to use LangGraph for stateful AI workflows with conditional routing, checkpointing, and human-in-the-loop patterns — and when it's overkill.

LangGraphWorkflowsState Machines
Akhil SharmaAkhil Sharma
Feb 22
What do you need?
│
├── Key-value lookup → String (GET/SET)
├── Object with fields → Hash (HGET/HSET)
├── Ordered collection → Sorted Set (ZADD/ZRANGE)
├── Unique membership → Set (SADD/SISMEMBER)
├── Queue / timeline → List (LPUSH/RPOP) or Stream (XADD/XREAD)
└── Append-only log → Stream (XADD/XREAD)
SYS
System Design10 min read

Redis Data Modeling for High-Throughput Systems

Choosing the right Redis data structures, memory optimization techniques, key naming conventions, and pipeline patterns for high-throughput production systems.

RedisData ModelingPerformance
Akhil SharmaAkhil Sharma
Feb 19
Traditional Monolith:                Modular Monolith:
┌─────────────────────┐             ┌─────────────────────┐
│                     │             │  ┌─────┐  ┌─────┐  │
│  Everything calls   │             │  │Order│  │ User│  │
│  everything. Shared │             │  │     │  │     │  │
│  database tables.   │             │  └──┬──┘  └──┬──┘  │
│  No boundaries.     │             │     │ events  │     │
│                     │             │  ┌──▼──┐  ┌──▼──┐  │
│                     │             │  │Inv. │  │Pay. │  │
└─────────────────────┘             │  │     │  │     │  │
                                    │  └─────┘  └─────┘  │
                                    └─────────────────────┘
                                    Each module has its own
                                    tables, APIs, and events.
ARCH
Architecture10 min read

The Modular Monolith: A Pragmatic Alternative to Microservices

How to build a modular monolith with strict module boundaries, internal event buses, and a clear extraction path to microservices when the time comes.

Modular MonolithArchitectureMicroservices
Akhil SharmaAkhil Sharma
Feb 14
┌──────────────┐         ┌──────────────┐
│  LLM Client  │◄──MCP──►│  MCP Server  │
│  (Claude,    │         │              │
│   IDE, etc.) │         │  ┌────────┐  │
│              │         │  │ Tools  │  │
│              │         │  ├────────┤  │
│              │         │  │Resources│ │
│              │         │  ├────────┤  │
│              │         │  │Prompts │  │
│              │         │  └────────┘  │
└──────────────┘         └──────────────┘
AI
AI Engineering10 min read

MCP Server Patterns for Tool-Augmented LLMs

Design patterns for building Model Context Protocol servers, from tool registration to transport options to authentication strategies.

MCPTool UseClaude
Akhil SharmaAkhil Sharma
Feb 13
# THE BUG: dual write
async def create_order(order: Order):
    await db.insert(order)           # Step 1: write to DB
    await kafka.produce(             # Step 2: publish event
        "order-created", order.to_event()
    )
    # What if the app crashes between step 1 and step 2?
    # DB has the order, but no event was published.
    # Downstream services never know about it.
```

This isn't a theoretical problem. Network partitions, process crashes, and deployment restarts all cause it. I've seen order fulfillment systems where 0.1% of orders were never processed because the event was lost.

### Solution: The Outbox Pattern

Write the event to a database table (the "outbox") in the same transaction as the business data. A separate process reads the outbox and publishes to Kafka.

![Outbox pattern — business data and event in one transaction, CDC publishes](/assets/excalidraw-png/event-driven-architecture-pitfalls/eda-outbox-pattern.png)

```sql
SYS
System Design10 min read

Event-Driven Architecture Pitfalls I've Seen in Production

Common failure modes in event-driven systems — ordering, schema evolution, duplicate handling, and the dual-write problem — with practical solutions.

Event-DrivenArchitectureDistributed Systems
Akhil SharmaAkhil Sharma
Feb 10
Forward flow:
Step 1: Create Order (order-service)
Step 2: Reserve Inventory (inventory-service)
Step 3: Charge Payment (payment-service)
Step 4: Schedule Shipment (shipping-service)

If Step 3 fails:
Compensate Step 2: Release Inventory
Compensate Step 1: Cancel Order
```

Key insight: compensating transactions don't "undo" in the database ROLLBACK sense. They're new transactions that semantically reverse the effect. An inventory reservation is compensated by releasing the reservation. A payment charge is compensated by a refund.

## Choreography: Event-Driven Sagas

Each service listens for events and decides what to do next. No central coordinator. Services communicate through events.

```
┌──────────┐  OrderCreated  ┌───────────┐  InventoryReserved  ┌─────────┐
│  Order   │───────────────▶│ Inventory │────────────────────▶│ Payment │
ARCH
Architecture11 min read

The Saga Pattern: Managing Distributed Transactions Without 2PC

Implementing the saga pattern with choreography and orchestration approaches, compensating transactions, and a real e-commerce order flow example.

Saga PatternDistributed TransactionsMicroservices
Akhil SharmaAkhil Sharma
Feb 6
┌────────────────────────────────────┐
│          Load Balancer             │
│    (GPU-aware routing)             │
└──────────────┬─────────────────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│vLLM   │ │vLLM   │ │vLLM   │
│Worker │ │Worker │ │Worker │
│(A100) │ │(A100) │ │(A100) │
└───┬───┘ └───┬───┘ └───┬───┘
    │          │          │
    └──────────┼──────────┘
               │
┌──────────────▼─────────────────────┐
│     Model Weights (Shared NFS/S3)  │
└────────────────────────────────────┘
AI
AI Engineering12 min read

LLM Serving Infrastructure at Scale

How to serve LLMs in production with vLLM, TGI, and TensorRT-LLM — covering batching, KV cache, quantization, and GPU memory management.

LLMInfrastructureGPU
Akhil SharmaAkhil Sharma
Feb 4
-- postgresql.conf tuning for a 64GB RAM, 16-core server

-- Memory
shared_buffers = '16GB'              -- 25% of RAM
effective_cache_size = '48GB'        -- 75% of RAM (OS cache + shared_buffers)
work_mem = '256MB'                   -- Per-operation sort/hash memory
maintenance_work_mem = '2GB'         -- VACUUM, CREATE INDEX

-- Write-Ahead Log
wal_buffers = '64MB'
checkpoint_completion_target = 0.9
max_wal_size = '4GB'
min_wal_size = '1GB'

-- Query Planner
random_page_cost = 1.1               -- SSD storage (default 4.0 is for spinning disks)
effective_io_concurrency = 200       -- SSD concurrent I/O
default_statistics_target = 500      -- More accurate query plans

-- Connections
SYS
System Design12 min read

PostgreSQL Scaling Patterns: From Single Node to Distributed

A progressive guide to scaling PostgreSQL through connection pooling, read replicas, partitioning, and sharding — with configuration examples and performance benchmarks.

PostgreSQLScalingDatabase
Akhil SharmaAkhil Sharma
Feb 2
Layer 3:  A ─────────────── D
Layer 2:  A ──── B ──────── D
Layer 1:  A ── B ── C ── D ── E
Layer 0:  A─B─C─D─E─F─G─H─I─J
AI
AI Engineering11 min read

Choosing a Vector Database: Benchmarks, Trade-offs, and Real-World Performance

A comparison of Pinecone, Weaviate, Qdrant, Milvus, and pgvector with indexing algorithms, filtering, and operational complexity analysis.

Vector DatabaseEmbeddingsSearch
Akhil SharmaAkhil Sharma
Jan 29
Client → Gateway → /api/users/*    → user-service
                 → /api/orders/*   → order-service
                 → /api/products/* → product-service
ARCH
Architecture10 min read

API Gateway Patterns for Microservices

API gateway routing, authentication offloading, BFF pattern, and comparing Kong, Envoy, and AWS API Gateway with configuration examples.

API GatewayMicroservicesKong
Akhil SharmaAkhil Sharma
Jan 25
Cache-Aside:                    Write-Through:
App → Cache (miss)              App → Cache → DB (sync)
App → DB → Cache (backfill)

Write-Behind:
App → Cache → [async queue] → DB
SYS
System Design10 min read

Cache Invalidation Strategies Beyond TTL

Advanced cache invalidation patterns including event-driven invalidation with CDC, tag-based eviction, and thundering herd mitigation techniques.

CachingRedisSystem Design
Akhil SharmaAkhil Sharma
Jan 22
┌────────────┐
         │ Supervisor │
         │   Agent    │
         └─────┬──────┘
               │
     ┌─────────┼─────────┐
     │         │         │
┌────▼───┐ ┌──▼─────┐ ┌─▼──────┐
│Research│ │Analysis│ │Writing │
│ Agent  │ │ Agent  │ │ Agent  │
└────────┘ └────────┘ └────────┘
AI
AI Engineering11 min read

Multi-Agent Orchestration: Patterns That Actually Work

Practical patterns for coordinating multiple LLM agents in production, including when single-agent with tools is the better choice.

Multi-AgentCrewAILangGraph
Akhil SharmaAkhil Sharma
Jan 20
Traditional:
┌────────────┐
│   Service   │──── Read/Write ────▶ Same Database
└────────────┘                      Same Schema

CQRS:
┌────────────┐     Commands      ┌──────────────┐
│            │──────────────────▶│ Write Model  │
│   Service  │                   │ (normalized) │
│            │                   └──────────────┘
│            │     Queries       ┌──────────────┐
│            │◀──────────────────│ Read Model   │
└────────────┘                   │(denormalized)│
                                 └──────────────┘
ARCH
Architecture11 min read

CQRS and Event Sourcing: When the Complexity Is Worth It

When CQRS and event sourcing justify their complexity, with event store design, projection building, snapshot strategies, and a cost-benefit analysis.

CQRSEvent SourcingArchitecture
Akhil SharmaAkhil Sharma
Jan 16
Producer ──── Message ────▶ Broker (stored ✓)
Producer ◄──── ACK ──────── Broker
                    ↑
                  LOST!

Producer ──── Message ────▶ Broker (duplicate!)
Producer ◄──── ACK ──────── Broker (this time ACK arrives)
SYS
System Design11 min read

Achieving Exactly-Once Delivery in Kafka: Theory vs Practice

How Kafka's idempotent producers, transactional APIs, and consumer coordination achieve exactly-once semantics — and when at-least-once is the smarter choice.

KafkaDistributed SystemsMessaging
Akhil SharmaAkhil Sharma
Jan 14
┌─────────────┐
                    │  Documents  │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │  Ingestion  │
                    │  Pipeline   │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
       ┌──────▼──┐  ┌─────▼─────┐ ┌───▼────┐
       │ Chunker │  │ Metadata  │ │ Parser │
       │         │  │ Extractor │ │        │
       └────┬────┘  └─────┬─────┘ └───┬────┘
            │              │           │
            └──────────────┼───────────┘
                           │
                    ┌──────▼──────┐
                    │  Embedding  │
AI
AI Engineering12 min read

Building Production RAG Pipelines That Don't Fall Apart

A practical guide to designing RAG systems that survive real-world traffic, covering chunking, retrieval quality, re-ranking, and the failure modes nobody warns you about.

RAGVector SearchLLM
Akhil SharmaAkhil Sharma
Jan 12
┌─────────────────────────┐
            │     Driving Adapters     │
            │  (HTTP, gRPC, CLI, etc.) │
            └────────────┬────────────┘
                         │
                    ┌────▼────┐
                    │  Ports  │ (Input interfaces)
                    │  (API)  │
                    ├─────────┤
                    │         │
                    │ Domain  │ (Business logic)
                    │  Core   │ (No external deps)
                    │         │
                    ├─────────┤
                    │  Ports  │ (Output interfaces)
                    │  (SPI)  │
                    └────┬────┘
                         │
            ┌────────────▼────────────┐
            │     Driven Adapters      │
ARCH
Architecture10 min read

Hexagonal Architecture in Practice: Beyond the Theory

Practical implementation of ports and adapters architecture with real code examples, dependency injection, testing strategies, and where teams over-engineer it.

Hexagonal ArchitecturePorts and AdaptersClean Code
Akhil SharmaAkhil Sharma
Jan 7
┌─────────────────────────────────────────┐
│           Total Context Window          │
│  ┌───────────┐ ┌──────────┐ ┌────────┐ │
│  │  System    │ │ Retrieved│ │ User   │ │
│  │  Prompt    │ │ Context  │ │ Query  │ │
│  │  (~2K)     │ │ (~8-12K) │ │ (~1K)  │ │
│  └───────────┘ └──────────┘ └────────┘ │
│  ┌──────────────────────────┐           │
│  │  Reserved for Generation │           │
│  │  (~4K)                   │           │
│  └──────────────────────────┘           │
└─────────────────────────────────────────┘
AI
AI Engineering10 min read

Context Engineering: The Most Important Skill of 2026

How to systematically design and manage the information you feed to LLMs, from token budgets to retrieval strategies to prompt structure.

Context WindowsPrompt EngineeringLLM
Akhil SharmaAkhil Sharma
Jan 5
-- fixed_window.lua
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])

local current = redis.call('INCR', key)
if current == 1 then
    redis.call('EXPIRE', key, window)
end

if current > limit then
    return 0  -- rejected
end
return 1  -- allowed
```

```python
def check_rate_limit(user_id: str, limit: int = 100, window: int = 60) -> bool:
    key = f"ratelimit:{user_id}:{int(time.time()) // window}"
    result = redis.eval(FIXED_WINDOW_SCRIPT, 1, key, limit, window)
SYS
System Design11 min read

Distributed Rate Limiting with Redis and Sliding Windows

Implementing distributed rate limiting with token bucket and sliding window algorithms in Redis, including Lua scripts for atomicity and multi-region challenges.

RedisRate LimitingDistributed Systems
Akhil SharmaAkhil Sharma
Jan 3