DEV Community: Darshil Mahraur

Scaling Voice Agents to 10,000+ Calls - Part 2: One Pod, One Call, with Agones

Darshil Mahraur — Sun, 18 Oct 2026 17:28:12 +0000

The Game Industry Solved My Problem Years Ago. I Found Out This Year.

Part 2: how we stopped fighting a multi-tenant Python process and started handing out fresh ones

Where We Left Off

Part 1 ended with a table. Three problems, VAD jitter, STT/TTS CPU bursts and a Daily.co native thread leak, and every one of them scaled with the same variable: how many calls one pod touches.

pod serving several calls:   hundreds of threads, heap at the limit, noisy neighbours, OOMKilled
pod serving one call:        one call's spikes, bounded memory, then it's gone

"The question that reframed it was simple: what if a pod only ever served one call, like a game server?"

So I looked at how game servers do it. The answer is Agones, a Kubernetes controller from Google and Ubisoft whose whole job is to keep a pool of ready game-server pods, hand exactly one to a match, and make sure nobody kills it mid-game.

Swap "match" for "call" and read that again. It fits, down to the failure modes.

This post is the build: the shape, the warm-pool math, the Karpenter settings that will drop a live call if you get them wrong, the two ways a pod leaks out of the pool, and copy-paste configs at the end.

The Shape of It

Part	Owns
Agones Fleet	N Ready pods and the `Ready → Allocated → Shutdown` state machine
FleetAutoscaler	keeps `replicas = allocated + bufferSize`
Karpenter NodePool	arm64 nodes appear when pods are Pending, vanish when empty
Stark (orchestrator)	allocates a pod, talks to it directly at `nodeIP:hostPort`, remembers the address
Jarvis	`Ready()` when warm, `Health()` heartbeats, `Shutdown()` when the call ends

Gone: the Istio DestinationRule from my last post, the Service as the call path, the HPA, the Redis routing map. Affinity stopped being a hash ring and became a stored address. Stark writes down the address it was given and end-call goes there.

The Lifecycle Is the Whole Design

Scheduled ──▶ Ready ──▶ Allocated ──▶ Shutdown
   boot        warm      in a call      deleted, backfilled

Two properties make this safe for calls:

Allocation is atomic. Ready → Allocated flips once. Agones never hands the same pod to two callers, so "one pod one call" is an invariant, not a convention.
Release is cooperative. Only the pod can leave Allocated, by calling Shutdown(). Agones never reclaims an Allocated pod for a scale-down or a rollout. A scale-down can never hang up on a user.

On the jarvis side that's three verbs on the SDK, ready(), health() and shutdown(), plus one rule that took me a while to internalize: the pod never exits itself. It calls Shutdown(), Agones deletes it.

The Warm Pool: N Ready Pods, Always

The first question everyone asks is "how many idle pods do you keep?" The intuitive answer, "enough for concurrent calls", is wrong. The Fleet already grows to allocated + N. Concurrency is handled by growth. The warm pool only has to cover the calls that arrive while a replacement pod is still booting.

So N is a function of two things: how fast calls arrive, and how long a fresh pod takes to reach Ready. Today N is a fixed number for us, tuned from load tests with headroom on top. Making it follow arrival rate automatically is the next step, and the FleetAutoscaler has a webhook policy for exactly that.

What this says about cost: cold start is the cost driver, not traffic. Halve the time to Ready and you halve the idle pool. So that is where the effort went:

Cold-start item	Before	After
pipecat import	lazy, on the first call	eager, at boot, before `Ready()`
Silero VAD load	on the start-call path	loaded at boot, first call adopts it
Daily room + token	REST round-trip on every start-call	prewarmed at boot
GC	everything tracked	`gc.collect(); gc.freeze()` after boot, so per-call collects scan only per-call garbage
Node provision	about a minute on top of pod boot	still about a minute, which is what the pool is sized for

In production, picking a pod takes tens of milliseconds at p95. The user doesn't know the pod didn't exist for them a moment ago.

Sizing a Pod, and Then a Node

Part 1's lesson was that CPU trouble lives in the spikes, not the average, and spikes from neighbouring calls collide. One pod per call removes the neighbours. What's left is sizing the pod so its own spikes never get throttled:

# Guaranteed QoS: requests == limits, set from one call profiled on its own.
resources:
  requests: { cpu: <one call's burst>, memory: <one call's peak working set> }
  limits:   { cpu: <one call's burst>, memory: <one call's peak working set> }

The node shape was a decision, not a default. One call's profile is lopsided: a meaningful slice of CPU for a modest amount of memory, roughly a 1:2 ratio of cores to GiB once the pod is sized Guaranteed. General-purpose instances come at 1:4, so a node packed with jarvis pods runs out of CPU with half its memory still empty, and you pay for RAM nobody uses. Compute-optimized Graviton, the C family, is 1:2.

Burstable (small request, bigger limit) packs about twice as many pods per node, and puts far more spike demand on the node than it has cores. The extra nodes are the price of never throttling a live call.

Karpenter: Four Settings That Will Drop a Live Call

A NodePool is a rule: "if a pod needs capacity like this, you may build a node like this." Nodes appear when pods are Pending and vanish when they empty.

1. Only remove a node when it is empty. Karpenter has two modes for cleaning up nodes. WhenEmptyOrUnderutilized says: if a node is only half used, move its pods somewhere else and delete it. That works for web servers, because any pod can be replaced by any other. It does not work here. "Moving" a jarvis pod means killing it, and there is a person on the call. So we use WhenEmpty: Karpenter may delete a node only when nothing is running on it.

2. Fill nodes up before starting new ones. Rule 1 has a catch. If Agones hands out calls evenly across all nodes, no node ever becomes empty, so no node is ever removed, and you keep paying for every node you ever created. scheduling: Packed on the Fleet tells Agones to put new calls on the fullest node first.

3. Tell Karpenter directly: do not touch this pod. Agones already marks a pod in a call as "do not evict", but it uses the annotation the old cluster-autoscaler understands. Karpenter ignores that one.

4. No spot instances. Spot gives about two minutes of warning before AWS takes the machine back. A warm pod turns into a live call in milliseconds, and a call lasts longer than two minutes. There is no pod in this pool that is safe to lose, so every node is on-demand.

The Two Ways a Pod Leaks Out of the Pool

"Only the pod can release itself" is a feature right up until the pod doesn't. A missed Shutdown() is permanent. The GameServer stays Allocated, still counts toward allocatedReplicas, and the autoscaler provisions a replacement for it.

How often does a pod get claimed and then not used? More than you'd guess. Here's one week of prod, about ten thousand calls started versus calls where the user actually reached the room:

The gap has two causes, and we see both every day:

(a) Started, but never joined. Stark allocated the pod, start-call landed, the pipeline is up and the Daily room is waiting. The participant never arrives. The idle timeout is what saves it, the pod tears the session down and calls shutdown() itself.

(b) Joined, then hung up before the call finished starting. The participant comes in and leaves while the pipeline is still being built, so end-call races start-call.

The alert that catches both: Allocated count versus Stark's live-call count. A persistent gap is a leaked pod.

What Changed

Same production environment, shared pods before, one-call pods after:

	Before	After
Threads per pod	hundreds	dozens
Heap per pod	at the limit, OOMKilled	bounded, no OOMKills since cutover
CPU	spikes colliding across calls	one call's spikes, Guaranteed QoS, no neighbours
Pod affinity	Istio hash ring, reshuffles on scale	the address Agones returned
Allocation latency	n/a, Service round-robin	tens of ms at p95
Capacity model	"how many calls fit in a pod?"	pods per node, linear
Risk to live calls from scaling	HPA + default scheduling	`WhenEmpty` + `Packed` + `do-not-disrupt` + on-demand

The architecture didn't fix the thread leak. The shielded release() from Part 1 did. What the architecture did is make the class of bug irrelevant. A process that serves one call and dies can't accumulate anything.

Three Things I Got Wrong

1. initialDelaySeconds lower than the cold start. The Agones health check counts from pod start. The heartbeat starts when lifespan startup finishes, tens of seconds in. Agones started checking, saw nothing, and killed every pod a few seconds before it would have gone Ready. No error anywhere. Just a Fleet at 0 Ready, forever.

2. Leaving the managed node group next to the Karpenter pool. In dev we kept an old node group with the same label and taint "while it's phased out". Nothing scales a managed node group, so overflow landed on Karpenter and Karpenter nodes stuck around because Packed kept filling them. Two schedulers, one label. Pick one.

3. Agones' Helm pre-delete hook. Upstream ships a hook that deletes every GameServer in the managed namespaces on chart delete. ArgoCD runs it whenever the Application is deleted, including an ApplicationSet regenerating it, and preserveResourcesOnDeletion doesn't stop hooks. On prod that is every live call, ended by a GitOps refactor. agones.crds.cleanupOnDelete: false, for good.

If You're In My Shoes

If you run realtime, stateful, one-user-at-a-time workloads, voice agents, video rooms, browser sessions, anything with a native SDK that holds threads, stop trying to make a multi-tenant process behave and look at Agones. It was built for exactly "hand out one fresh process per session and never kill it mid-session".

Three rules:

The pod never exits itself. Shutdown(), then let SIGTERM run your teardown.
Every path to an Allocated pod ends in Shutdown(). Failed starts included. Alert on Allocated versus your own live-session count.
WhenEmpty + Packed + do-not-disrupt + on-demand. Drop any one and Karpenter will eventually hang up on someone.

Jarvis: the lifecycle. Python, the shape of it:

# lifespan startup
await transport_service.prewarm()     # Daily room + token, off the critical path
prewarm_vad()                          # Silero, off the critical path
gc.collect(); gc.freeze()
await agones.ready()                   # LAST: joins the pool only when actually warm

# every call-ending path converges here
await publish_call_terminated(...)     # the end event first, billing depends on it
await cleanup_session(...)             # EndFrame → Daily release(), shielded, never cancelled
await agones.shutdown()                # hand the GameServer back. Do NOT os._exit.

Watch these

# warm pool depth, alert when it gets thin
sum(agones_gameservers_count{fleet_name="<fleet>", type="Ready"})

# leaked Allocated pods, alert when this stays above your live-call count
sum(agones_gameservers_count{fleet_name="<fleet>", type="Allocated"})

# the autoscaler is actually allowed to scale (0 = frozen at current replicas)
min(agones_fleet_autoscalers_able_to_scale)

# throttling on a Guaranteed pod should be ~0
sum(rate(container_cpu_cfs_throttled_periods_total{container="<app>"}[5m]))
  / sum(rate(container_cpu_cfs_periods_total{container="<app>"}[5m]))

# nodes the fleet is holding
count(count by (node) (container_memory_working_set_bytes{container="<app>"}))

Two posts ago the answer was "hash the session header". One post ago it was "count the threads". This time it was "stop sharing the process".

Every one of those was right for the problem in front of me. None was the last answer. That's how infrastructure evolves, and honestly, watching a Fleet backfill a pod in the time it takes to say hello is a pretty good feeling.

Scaling Voice Agents to 10K+ Calls: Jarvis’s 3 Biggest Challenges: Part 1

Darshil Mahraur — Sun, 18 Oct 2026 12:21:05 +0000

I Fixed Routing. Then I Found Out Routing Was Never the Real Problem

From "the pods keep dying" to "oh, it's the architecture"

Where We Left Off

In my last post I replaced a Redis session-affinity lookup with Istio consistent hashing. WebRTC drops stopped. We saved money. I felt clever.

Then we tried to actually scale Jarvis.

Jarvis is our real-time voice agent. It brokers a Daily.co WebRTC room per call and runs a pipecat pipeline: user speaks → VAD → STT → LLM → TTS → bot speaks. The LLM lives in Stark, our orchestrator. Jarvis is the audio edge. One pod served several calls at once, like any normal web service.

Here is what "normal web service" thinking got us:

jarvis-xxxxx   RESTARTS: 1   LAST STATE: OOMKilled
  heap:        pressing against the memory limit
  OS threads:  in the hundreds
  live calls:  a handful

A handful of calls. Hundreds of threads. Consistent hashing had nothing to do with it.

This post is the autopsy: three problems, what each one did to CPU and memory, and the one variable they all share. Part 2 is the rebuild with Agones and Karpenter, one pod per call.

What One Call Costs

Per call: one WebRTC peer, two vendor WebSockets, one SSE stream, one ONNX model scoring audio about 30 times a second, and a pile of resampling. All inside one Python process, under one CPU limit, sharing one memory limit.

That limit was small. A few hundred millicores and well under a gigabyte, because that's what a web service pod looks like. Everything below is a fight over it.

Here is what that fight looked like in prod, back when jarvis was a plain Deployment. Three pods sharing calls, two days, real data:

Two things to hold onto. The CPU panel sits near zero and jumps in short spikes, and every spike is a call doing something: someone talking, a call starting, a TTS burst going out. The memory panels are a staircase. We'll come back to both.

Problem 1: VAD Isn't CPU-Hungry. It's CPU-Sensitive.

VAD decides when the user has stopped talking. In pipecat that's Silero, an ONNX model scoring every short chunk, plus a stop_secs timer: once the score drops below confidence for stop_secs seconds, the turn ends and the transcript goes to the LLM.

@dataclass
class VAD:
    confidence: float   # how sure the that this is speech
    start_secs: float   # how long speech must persist before "user started"
    stop_secs:  float   # how long silence must persist before "user stopped"
    min_volume: float   # below this, don't even ask the model

The catch: stop_secs is wall-clock time, but the chunks arrive through a process that can be throttled. Late chunks look like silence.

What happened on our pods:

Loading Silero costs tens of ms of CPU per call. Under the pod's CPU limit that stretched to several times longer in wall time, on the start-call path.
Look at the CPU panel again. Between turns a pod sits near zero. When someone talks it spikes, and the spike is short. The kernel doesn't bill the average. It bills 100 ms slices against the quota.
When that happens, the logs look like this:

[VAD] user stopped speaking      (stop_secs of "silence": really stop_secs of late chunks)
[STT] flush → LLM                "I was going to say that"
[VAD] user started speaking      (the chunks finally arrive)
[STT] flush → LLM                "we should probably"
→ two LLM turns for one sentence. User hears two replies.

We called these "duplicate messages". The first fix is in git history and I'm not proud of it:

bump STTToTextProcessor response timeout (band-aid for duplicate messages)

Over the next few months we also loosened confidence and min_volume and shortened stop_secs, because VAD "wasn't firing". Some of that was real. Some of it was us tuning a model to compensate for a starved process.

CPU: VAD's own cost is small. Its sensitivity to throttling is total. It's the canary.
RAM: a few MB per analyzer. Not the memory problem.

Problem 2: STT/TTS Traffic Is Where the CPU Goes

My first theory was Python. Single-threaded, GIL, two calls step on each other, done. I had that paragraph written. Then I remembered we'd run TTS to a bunch of devices off one process without anything choking.

So I measured it. Two threads of pure Python loops take turns, textbook GIL. But the audio work a call does, resampling and VAD inference, is C and C++ underneath. It drops the GIL and runs on two cores just fine. The Daily client's threads don't ask Python at all.

Python wasn't the bottleneck. The pod's CPU budget was. Parallel threads don't get around a budget. They spend it faster.

Where a call's CPU goes:

Stage	Work	When
Mic → STT	chunk, frame, send, parse transcripts, decide when to flush	while the user speaks
TTS → pod	receive, resample, cut into 20 ms frames, hand to the native client	while the bot speaks
Native client	Opus encode/decode, jitter buffer, WebRTC	always, both legs
Vendor failover	tear down one WebSocket, open another, mid-turn	rare, expensive

None of it is heavy alone. Each one is a spike on that CPU panel. Put calls together on one pod and it goes like this:

Our load tester Voldemort, exists because of this table. One Locust user is one whole call: real STT, mock TTS and LLM with measured vendor latencies baked in. An instant mock makes a pod look several times more capable than it is.

CPU: the bulk of the in-call burst.
RAM: a bounded working set per live call. If this were the only memory cost we'd never have OOMed.

So why did we OOM?

Problem 3: The Daily.co Thread Leak

Python asyncio code doesn't make hundreds of threads. Something native does.

daily-python wraps Daily's C++ WebRTC client. Every call creates one, and every client starts roughly ten OS threads. You'll see names like SoupSignalling and mediasoup-manag in /proc/<pid>/task/*/comm. Those threads and the client's audio buffers are freed by exactly one thing: daily.release().

In pipecat, release() runs at the very end of pipeline teardown, after an EndFrame has flowed through every processor. Our teardown under load:

end-call arrives
  → stop_pipeline()
    → queue EndFrame
    → wait for runner ... timeout ...
    → task.cancel()          ← "fallback if the pipeline does not finish"
  → drop transport reference
  → gc.collect()

task.cancel() cancels the Python coroutine. It does not call release() on the C++ client. The Python object gets collected. The ten threads and the buffers don't. They were never Python's to collect.

And once we dropped our reference, our "active transports" gauge went back to zero. Our metric said clean. The kernel said hundreds of threads.

Back to the screenshot from the top. CPU is quiet. Memory is a staircase, and there isn't a single step down in two days. Every step is a call that ended and left something behind. Three pods, same slope, so not one bad pod or one bad user.

The Fixes That Weren't

Every one of these felt like progress at the time:

Attempt	What it did	Why it wasn't enough
Double the memory limit	OOMed slower	Leak is unbounded
`memray` in prod	Clean heap snapshots of Python objects	Leak was native
`gc.collect()` after every cleanup	Reclaimed the Python cycle	No effect on C++ threads
jemalloc	RSS tracked real usage	Can't free what was never freed
Redis snapshots + `/resume-call`	Calls survived a pod crash	We built resume-on-crash instead of not crashing. Deleted later
Istio consistent hashing	`end-call` reaches the right pod	Until a scale event moves the ring. Then `end-call` lands on the wrong pod and the call runs to the watchdog

That last row is my previous post. Hashing was correct. It only mattered because one pod held state for many calls. We solved routing to a stateful pod without asking why the pod was stateful for more than one call.

The actual leak fix is small:

# daily.release() is the only thing that reclaims the native client's
# threads and buffers. Never cancel it.
release = spawn(transport.cleanup(), name=f"daily-release-{session_id}")
for timeout in (_RELEASE_TIMEOUT_SECONDS, _RELEASE_GRACE_SECONDS):
    try:
        await asyncio.wait_for(asyncio.shield(release), timeout=timeout)
        return
    except TimeoutError:
        logger.warning("[MEMORY] Daily release slow, still waiting")

Shield the release. Prune the transport entry only after it completes, so the gauge stays honest. That stopped the bleeding. It didn't change the fact that one pod was juggling several realtime pipelines on a web-service CPU limit.

The Comparison That Changed the Architecture

Problem	Bottleneck	Per call	Scales with	Shows up as
VAD jitter	CPU (sensitivity)	tiny, first to feel a throttle	calls per pod, superlinearly	duplicate turns
STT/TTS traffic	CPU (volume)	most of the burst	calls per pod, linearly	throttled periods, late TTS
Daily thread leak	RAM + threads	tens of MiB, ~10 threads per leaked call	calls ever served by the pod	OOMKilled

This reframed it to:
"What if a pod only ever served one call? Like a game server. One match, then it exits."

Then nothing leaks across calls, because there is no across calls. VAD never competes with another call's TTS, because there are no neighbours. CPU per pod is one call's spikes and nothing else. Memory per pod is one call's working set, and then the process is gone. Routing is "the pod I was given".

The problem collapses from "make a multi-tenant realtime Python process behave" to "hand out fresh processes fast enough". That's a scheduling problem, and the game industry solved it years ago.

If You're In My Shoes

If you run a native SDK in Python on Kubernetes and you see threads creeping up while your metrics say clean, memory that only goes up, or endpointing that's flaky only under load, don't start with the model params. Count the threads.

# 1. threads, not memory
kubectl exec <pod> -- ls /proc/1/task | wc -l

# 2. what the threads are
kubectl exec <pod> -- sh -c 'cat /proc/1/task/*/comm | sort | uniq -c | sort -rn | head'

# 3. real heap vs cache
kubectl exec <pod> -- grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat

For CPU, watch throttled periods, not the usage average. The average is what the spikes look like after Grafana flattens them:

rate(container_cpu_cfs_throttled_periods_total{container="<app>"}[5m])
  / rate(container_cpu_cfs_periods_total{container="<app>"}[5m])

And one more, because container_oom_events_total read zero in our cluster even for pods that were genuinely OOMKilled:

max_over_time(kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}[14d]) > 0

Part 2: how we rebuilt Jarvis as a one-pod-one-call fleet on Agones with Karpenter supplying nodes, the warm-pool formula N = x + 3√x, the three ways a pod can leak out of the pool, and the arithmetic to 10,000 concurrent calls.

It's not as clever as consistent hashing. It's a lot more boring. In the best way.

Saving $300/Month While Fixing WebRTC Drops: How Istio's Consistent Hashing Beat Redis

Darshil Mahraur — Mon, 30 Mar 2026 12:39:05 +0000

I Spent hours Debugging Sessions Until I Discovered Istio Consistent Hashing

A developer's journey from late-night debugging to elegant infrastructure solutions

The Problem That Started a Journey

We had a scaling problem that wouldn't go away.

Our Jarvis service needed to grow. We were scaling from 3 pods to handle more AI inference requests and audio interactions. But there was a critical issue: each Jarvis pod maintained state—model weights loaded in memory, WebRTC connections via daily.co for live audio calls, cached inference results.

When requests bounced randomly between pods (thanks, round-robin load balancer), things broke:

Request 1 (user-123) → Jarvis-Pod-1
  ✓ Model weights loaded, WebRTC connection active

Request 2 (user-123) → Jarvis-Pod-2 (different pod!)
  ✗ "Connection lost" - WebRTC drops
  ✗ Model weights reloaded - 500ms latency spike
  ✗ User's audio call freezes mid-session

Request 3 (user-123) → Jarvis-Pod-1
  ✓ Works again, but connection restarted

Month 1: We implemented Redis

The natural solution was to implement session affinity with Redis. Smaran-v2 would query Redis: "which Jarvis pod for this user?" and route accordingly. It worked well. WebRTC connections stayed alive, latencies improved, users were happy.

But as we scaled, the economics changed:

Cost: $300/month for a Redis cluster
Latency overhead: Every request made a network hop to Redis (5-10ms per request)
Operational toil: TTL management, replica failovers, cache invalidation edge cases

Redis solved the problem, but the cost-benefit ratio wasn't sustainable. We were paying premium dollars for a solution that was becoming a bottleneck. There had to be a more elegant way.

After some R&D: We discovered Istio

Digging through Kubernetes networking docs, I found something elegant: Istio's consistent hashing. No external service. No Redis. Just hash the session ID, map it to a pod—all built into the load balancer.

"Wait, we can remove Redis?" I asked.

"Apparently. Let's build a POC."

What started as a "maybe this could work" conversation turned into a proof-of-concept that would reshape our infrastructure.

My first thought: This is going to be a long night.

The Problem I Didn't Know I Had

Here's the setup. We have two main services:

User Request
    │
    ▼
┌─────────────────────────┐
│   Smaran-v2             │ (coordinator)
│   Routing requests to   │
└──────────┬──────────────┘
           │
           ▼
   ┌───────┴────────┐
   │                │
 Pod-1          Pod-2          Pod-3
 Jarvis         Jarvis         Jarvis
 (w/ state)     (w/ state)     (w/ state)
 (WebRTC)       (WebRTC)       (WebRTC)

Jarvis is the workhorse—it runs AI inference, maintains WebRTC connections via daily.co, and caches model state. We needed to scale it to many pods, which introduced the session affinity problem.

The Jarvis pods weren't just serving requests—they were stateful. Each pod maintained:

Model weights in memory (500MB loaded per pod)
Per-user WebRTC connections via daily.co for audio calls

That last one was critical. When a user started a audio call with daily.co, the Jarvis pod opened a WebRTC connection to participate in that session. If the next request hit a different pod, that connection was completely lost. The WebRTC peer would see a disconnect. The user would see: "Connection lost."

So here's what was happening with Jarvis:

User starts audio call:
Request 1 → Jarvis-Pod-1
  ✓ Creates daily.co WebRTC connection
  ✓ Stream is live

User sends inference request:
Request 2 → Jarvis-Pod-2 (different pod!)
  ✗ Pod-2 has no WebRTC connection
  ✗ Connection drops
  ✗ audio feed freezes

User tries again:
Request 3 → Jarvis-Pod-1
  ✓ Pod-1 still has the connection
  ✓ audio works again (but connection restarted)

And that wasn't even counting the raw performance penalty when a request hit a different Jarvis pod just because Kubernetes's default load balancer said "hey, let's send this request to a different Jarvis pod today."

I definitely knew something was wrong now. That's not something you ignore.

The Debugging Session from Hell

I spent the next few days chasing ghosts:

Day 1: "Must be a database performance issue." Checked query logs. Queries were fine.
Day 2: "Models are degrading?" Profiled inference on a single pod. Blazingly fast.
Day 3: "Network latency?" Ran iperf between pods. Nothing unusual.
Day 4: I added logging to see which pod each request was hitting. That's when it clicked:

Request 1: user-12345 → Pod-1 (100ms) ✓
Request 2: user-12345 → Pod-2 (850ms) ✗ CACHE MISS
Request 3: user-12345 → Pod-3 (900ms) ✗ COLD START
Request 4: user-12345 → Pod-1 (100ms) ✓
Request 5: user-12345 → Pod-2 (850ms) ✗ CACHE MISS

The pattern was unmistakable. The same user's requests were bouncing around like a pinball machine.

First Attempt: The Redis Solution

Need to pin users to pods.

So we built a Redis solution. The idea was straightforward: maintain a mapping of user_id → pod_name (stateful) (where we know the pod name) in Redis.

It worked. Users stopped getting disconnected. WebRTC connections stayed alive. We felt clever.

Then we started scaling.

The Redis Problem:

Every request hit Redis - All traffic went through Redis first. With 10k req/sec, that's 10k Redis lookups per second.
Redis became a bottleneck - We had to add read replicas, tune connection pools, add caching layers.
Cost was insane - A large Redis cluster to handle our traffic? That's several hundred dollars per month.
Failover was sketchy - When Redis went down, pod assignment failed. Users got randomly routed. WebRTC connections dropped again.
TTL management was tricky - Set it too short and sessions expire mid-interaction. Set it too long and stale mappings pile up. We were constantly tuning this.
We could've coded it, but why? - Implementing session affinity logic directly in Smaran-v2 (consistent hashing code, pod registry, health checks, failover logic). But that would mean:
- Infrastructure logic bleeding into application code
- Every service that needs affinity has to reimplement this
- Scaling to new services means copy-paste the same logic again

We realized: "This isn't an application concern. This is infrastructure's job."

After two months of fighting Redis, our tech lead ARP said:

"Have you looked at service meshes? Specifically Istio?"

I hadn't. But ARP's mention was enough to get me digging.

That evening, I started exploring Istio's documentation. The concept of consistent hashing at the networking layer—no Redis, no external state, everything baked into the load balancer—kept gnawing at me.

I read through how DestinationRules work, how Envoy proxies handle traffic routing, and what consistent hashing actually means in practice. The deeper I dug, the more a question crystallized in my mind:

"Wait... so Istio could handle session affinity for us? Without any application code changes? Just configuration?"

Every resource I read pointed to the same answer: yes.

Exploring Istio for Our Use Case

I wasn't immediately convinced this would work for us. Our architecture was specific: Smaran-v2 needed to route requests to specific Jarvis pods based on user session. I had to figure out:

How does consistent hashing actually work in Istio? Dug into the DestinationRule spec and Envoy documentation.
How do we map our user session to a hashing key? We'd need to send a header (like x-call-session-id) that Istio could hash.
Will it actually solve the WebRTC affinity problem? Traced through the request flow to confirm pods would stay consistent.
What are the operational implications? Could we fail over gracefully? What happens when we scale pods?
How fast could we POC this? Estimated timeline for testing without impacting production.

The more I explored, the more elegant it seemed. Not a quick patch like Redis, but a real architectural improvement.

By the end of that week, I was convinced. Here's what made it click:

The Promise:

No external Redis cluster
Session affinity baked into the load balancer
Lower latency (no Redis hop)
Lower cost (no monthly bill)
Reduced operational complexity

The Technical Elegance:
Instead of "all requests from this IP go to Pod-1" (which breaks for our users behind a VPN), Istio offers: "all requests with x-call-session-id: user-12345 go to Pod-2."

And the brilliant part? The hashing is consistent. When we scale from 3 to 10 pods, most requests still map to the same pod. Only ~30% of traffic rebalances. Compare that to round-robin, where all traffic redistributes.

"Let's build a POC," I told the team. "If this works, we can retire Redis."

The Key Insight: DestinationRule

Here's the magic piece. In Istio, you define how traffic should be handled with a DestinationRule. Instead of maintaining Redis mappings, Istio computes the pod assignment on-the-fly using consistent hashing.

I created one for Jarvis:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: jarvis-consistent-hash
  namespace: dev
spec:
  host: jarvis-service.dev.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-call-session-id"
    connectionPool:
      http:
        h2UpgradePolicy: UPGRADE

Let me break down what I was actually doing here:

`httpHeaderName: "x-call-session-id"`

This is the magic. Istio looks at the x-call-session-id header in each request, hashes it, and maps it to a pod. Same header value = same pod, always.

Unlike Redis, there's no external lookup. No network hop. No TTL management. The hash is deterministic and instant. If we have 3 pods and hash the value user-12345, it always maps to Pod-2. If we add a 4th pod tomorrow, most requests still map to the same pod (that's the magic of consistent hashing).

Compare to our Redis approach:

Aspect	Redis Solution	Istio Consistent Hash
Speed	~5-10ms lookup time	<1ms hash computation
Cost	$300+/month for Redis cluster	Built-in, $0
Failover	Redis goes down = broken	No external dependency
Scaling	All traffic rebalances	~1/N rebalance on N→N+1 pods
Operational burden	Tune TTL, manage replicas	Write YAML, forget about it

We literally saved money and got better performance by removing a dependency.

`h2UpgradePolicy: UPGRADE`

This one I learned the hard way. Without it, HTTP/1.1 connections weren't upgrading to HTTP/2. This meant connection pooling wasn't working as expected, and latencies were still higher than they should be. Added this line, and suddenly connection reuse kicked in.

This was especially important for our daily.co WebRTC connections—keeping TCP connections alive and reusing them meant the WebRTC establishment was faster.

The VirtualService: Routing Rules

But wait, where does the header actually come from? I had to ensure Smaran-v2 was sending that header to Jarvis.

I added a VirtualService to route traffic intelligently:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: jarvis-routing
  namespace: dev
spec:
  hosts:
    - jarvis-service.dev.svc.cluster.local
  http:
    # Route with header (gets consistent hashing)
    - match:
        - port: 80
          headers:
            x-call-session-id:
              regex: ".+"
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s
    # Fallback without header (round-robin)
    - match:
        - port: 80
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s

The first block handles requests with the header (these get consistent hashing). The second block is a fallback for requests without the header (they just get round-robin load balancing).

I added that fallback after almost shipping without it. Then I thought: "What if Smaran-v2 forgets the header? What happens?" With the fallback, they still work—they're just not affinity-pinned. That felt reasonable.

mTLS: The Security Layer I Didn't Expect to Need

While setting all this up, our security team (finally) looked at the architecture. They asked a simple question: "Are services talking over plain HTTP?"

Uh. Yes.

Their response was essentially: "Fix that."

Istio made this stupidly easy. One more YAML file:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

STRICT mode means: if you try to talk to our services over plaintext, it gets rejected. Mutual TLS is enforced everywhere.

I was nervous about this breaking things. Turned out Istio handles the certificate generation and rotation automatically. Zero intervention from us. By the next morning, all inter-service traffic was encrypted.

How It Works: The Request Flow (Redis vs. Istio)

Now here's where Istio became elegant. Let me trace a real request through our system, comparing the two approaches:

OLD REDIS APPROACH (Worked well, but had trade-offs):
1. Client sends request to Smaran-v2 with user-12345 and audio call
2. Smaran-v2 queries Redis: "which Jarvis pod for this user?"
3. Redis lookup: 5-10ms latency
4. Returns: "jarvis-pod-1"
5. Smaran-v2 routes to jarvis-pod-1 directly
6. jarvis-pod-1 has the WebRTC connection and session state
✓ Works reliably, but adds latency and operational overhead

NEW ISTIO APPROACH (Current, way better):
1. Client makes request with session header:
   GET /inference
   Headers: {
     "x-call-session-id": "user-12345-session-audio"
   }

2. Smaran-v2 receives it
   ✓ Extracts x-call-session-id
   ✓ Forwards to Jarvis service with header intact
   (No Redis query needed!)

3. Istio's Envoy Proxy (sidecar in Smaran-v2 or at service boundary) intercepts:
   ✓ Reads x-call-session-id: "user-12345-session-audio"
   ✓ Hashes the value: hash("user-12345-session-audio") = 8421
   ✓ Maps to pod ring: 8421 % N_pods = Jarvis-Pod-1
   ✓ Routes request to jarvis-pod-1
   (All done in <1ms, no external calls!)

4. Jarvis Pod-1 processes request:
   ✓ Session state is hot in memory
   ✓ Model weights already loaded (500MB)
   ✓ WebRTC connection to daily.co is ALIVE
   ✓ Inference completes in ~95ms

5. User continues audio call, sends next inference request:
   Same x-call-session-id header → Jarvis-Pod-1 again
   ✓ WebRTC connection stays open
   ✓ Session context preserved
   ✓ No cold starts, no reconnections
   ✓ Smooth user experience

The difference? Istio eliminates the Redis hop entirely. Same consistent routing, but with:

No external service dependency
Sub-millisecond routing decisions
Zero additional cost
Cleaner architecture

And the WebRTC connections? They stay alive now. The latency improvement alone was worth the migration.

Three Things I Got Wrong (and Learned)

1. Thinking about hashing too much

I spent hours worrying about hash collisions, ring rebalancing, edge cases. In practice? Istio just works. The consistent hash algorithm is proven, and Envoy has optimized it to death. I was overthinking.

2. Not understanding the fallback behavior

I added the VirtualService fallback thinking "this is fine, they'll just get round-robin." Turns out, I should have been more explicit about requiring the header.

In production, we now validate that x-call-session-id is present in Smaran-v2 before it forwards anything to Jarvis. If it's missing, we reject it with a clear error. That's much better than silently degrading to round-robin load balancing and potentially breaking WebRTC connections.

3. Forgetting that Istio adds latency (sometimes)

The Envoy proxy running in each pod adds... actually, negligible latency. Maybe 1-2ms per request for header parsing and routing decisions. But I was paranoid about it anyway. Added observability metrics to track proxy latency specifically. Turned out I was worry for nothing.

When We Scale to 10 Jarvis Pods

This is where the real test will come.

When we scale from 3 to 10 Jarvis pods, I won't expect chaos—but I'll be watching closely. Here's what should happen:

Traffic will redistribute smoothly
No request storms
Existing WebRTC connections will stay pinned to their original pods
New requests will get distributed to the new pods based on their session IDs

It should be... boring. Anticlimactically boring. In the best way.

Pod utilization will spread evenly. Latencies will stay low. The on-call engineer (me) won't get paged.

Redis vs. Istio: The Comparison

After six months running both in different parts of our infrastructure, the choice became unmistakable. Here's how they compare side-by-side:

Aspect	Redis Solution	Istio Consistent Hashing
Architecture	External state store (Redis cluster)	Built into load balancer (no external service)
Cost	$300+/month	$0 (included with Istio)
Latency per Request	5-10ms (Redis lookup)	<1ms (hash computation)
Setup Complexity	Moderate (Redis deployment, tuning)	Low (2 YAML files)
Operational Burden	High (failover, TTL tuning, replicas)	Minimal (Istio manages it)
Network Calls per Request	Every request → Redis	Zero (local routing)
Failure Mode	Redis down → random routing → WebRTC drops	Graceful, no single point of failure
WebRTC Reliability	15-20 disconnects/hour	<1 disconnect/month
Scaling 3→10 pods	100% traffic rebalances (TTL expires)	~30% traffic rebalances (hash ring)
Developer Experience	"Query Redis, route" (app code)	"Send x-call-session-id header" (config)
Testing	Requires Redis mock + K8s API mock	No mocks needed
Scalability Limit	Redis throughput limits growth	Scales linearly with pods

The Verdict: Redis solved the immediate problem. Istio solved it better. Why maintain a separate service for something the routing layer can handle elegantly?

We haven't touched Redis since the migration. Consistent hashing is now foundational to our system—it's in the runbooks, baked into deployments, and new team members learn about it early. WebRTC stability through daily.co is rock solid.

The lesson: you solve a problem one way, it works, you move forward. Then someone shows you a smarter approach, and you realize the trade-offs weren't necessary. That's how infrastructure evolves.

If You're In My Shoes

If you're running stateful services in Kubernetes with WebRTC or persistent connections, or if you're seeing weird latency patterns that don't make sense, or if you're scaling and watching your p99 latencies explode—look into Istio's consistent hashing.

It might save you a 3 AM debugging session (and a lot of frustrated users with dropped audio calls).

The Configs (Copy-Paste Ready)

Save these three files and apply them:

destination-rule.yaml:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: jarvis-consistent-hash
  namespace: dev
spec:
  host: jarvis-service.dev.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-call-session-id"
    connectionPool:
      http:
        h2UpgradePolicy: UPGRADE

virtual-service.yaml:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: jarvis-routing
  namespace: dev
spec:
  hosts:
    - jarvis-service.dev.svc.cluster.local
  http:
    - match:
        - port: 80
          headers:
            x-call-session-id:
              regex: ".+"
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s
    - match:
        - port: 80
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s

peer-authentication.yaml:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

Deploy:

# Install Istio (if needed)
istioctl install --set profile=demo -y

# Label namespace for auto-injection
kubectl label namespace dev istio-injection=enabled

# Apply configs
kubectl apply -f destination-rule.yaml virtual-service.yaml peer-authentication.yaml

# Restart deployments to pick up new routing
kubectl rollout restart deployment/smaran-v2 -n dev
kubectl rollout restart deployment/jarvis -n dev

Test it:

# From Smaran-v2 or a test pod, send multiple requests with the same header
kubectl run -it debug --image=curlimages/curl --rm --restart=Never -- sh

# Then:
for i in {1..5}; do
  curl -H "x-call-session-id: test-user-123" \
       http://jarvis-service:80/inference
  sleep 1
done

# Watch the Jarvis pod logs and you'll see each request hitting the same pod
# Each request should be fast (no cold starts)

That's the story. From 3 AM panic to elegant infrastructure. From debugging in the dark to understanding why the system works.

It's a pretty good feeling.

Go Programming: A Beginner's Guide

Darshil Mahraur — Thu, 26 Jun 2025 21:00:12 +0000

This is a placeholder for the article body. It would contain introductory material on Go programming.

Building a Smart Task Manager with JavaScript: From Concept to Code

Darshil Mahraur — Thu, 26 Jun 2025 20:55:44 +0000

Building a Smart Task Manager with JavaScript: From Concept to Code

In this tutorial, we'll build a feature-rich task manager application using vanilla JavaScript. This project will demonstrate key JavaScript concepts including DOM manipulation, local storage, event handling, and modern ES6+ features.

🎯 What We're Building

Our task manager will include:

Add, edit, and delete tasks
Task categories and priorities
Due date tracking
Local storage persistence
Search and filter functionality
Responsive design

🏗️ Project Structure

task-manager/
├── index.html
├── styles.css
├── script.js
└── README.md

💻 The JavaScript Implementation

Let's dive into the core JavaScript functionality:

1. Task Class and Data Structure

class Task {
  constructor(id, title, description, category, priority, dueDate, completed = false) {
    this.id = id;
    this.title = title;
    this.description = description;
    this.category = category;
    this.priority = priority;
    this.dueDate = dueDate;
    this.completed = completed;
    this.createdAt = new Date().toISOString();
  }

  // Method to check if task is overdue
  isOverdue() {
    if (!this.dueDate || this.completed) return false;
    return new Date(this.dueDate) < new Date();
  }

  // Method to get days until due
  getDaysUntilDue() {
    if (!this.dueDate) return null;
    const diffTime = new Date(this.dueDate) - new Date();
    return Math.ceil(diffTime / (1000 * 60 * 60 * 24));
  }
}

2. TaskManager Class - The Heart of Our Application

class TaskManager {
  constructor() {
    this.tasks = this.loadTasks();
    this.currentFilter = 'all';
    this.currentSort = 'dueDate';
    this.initializeEventListeners();
    this.renderTasks();
  }

  // Load tasks from localStorage
  loadTasks() {
    const savedTasks = localStorage.getItem('tasks');
    if (savedTasks) {
      return JSON.parse(savedTasks).map(taskData => 
        new Task(
          taskData.id,
          taskData.title,
          taskData.description,
          taskData.category,
          taskData.priority,
          taskData.dueDate,
          taskData.completed
        )
      );
    }
    return [];
  }

  // Save tasks to localStorage
  saveTasks() {
    localStorage.setItem('tasks', JSON.stringify(this.tasks));
  }

  // Add a new task
  addTask(taskData) {
    const task = new Task(
      Date.now().toString(),
      taskData.title,
      taskData.description,
      taskData.category,
      taskData.priority,
      taskData.dueDate
    );

    this.tasks.push(task);
    this.saveTasks();
    this.renderTasks();

    // Show success notification
    this.showNotification('Task added successfully!', 'success');
  }

  // Update an existing task
  updateTask(id, updates) {
    const taskIndex = this.tasks.findIndex(task => task.id === id);
    if (taskIndex !== -1) {
      Object.assign(this.tasks[taskIndex], updates);
      this.saveTasks();
      this.renderTasks();
      this.showNotification('Task updated successfully!', 'success');
    }
  }

  // Delete a task
  deleteTask(id) {
    this.tasks = this.tasks.filter(task => task.id !== id);
    this.saveTasks();
    this.renderTasks();
    this.showNotification('Task deleted successfully!', 'info');
  }

  // Toggle task completion
  toggleTask(id) {
    const task = this.tasks.find(task => task.id === id);
    if (task) {
      task.completed = !task.completed;
      this.saveTasks();
      this.renderTasks();
    }
  }

  // Filter tasks based on status
  filterTasks(filter) {
    this.currentFilter = filter;
    this.renderTasks();
  }

  // Get filtered tasks
  getFilteredTasks() {
    let filteredTasks = [...this.tasks];

    // Apply status filter
    switch (this.currentFilter) {
      case 'active':
        filteredTasks = filteredTasks.filter(task => !task.completed);
        break;
      case 'completed':
        filteredTasks = filteredTasks.filter(task => task.completed);
        break;
      case 'overdue':
        filteredTasks = filteredTasks.filter(task => task.isOverdue());
        break;
    }

    // Sort tasks
    filteredTasks.sort((a, b) => {
      switch (this.currentSort) {
        case 'dueDate':
          if (!a.dueDate && !b.dueDate) return 0;
          if (!a.dueDate) return 1;
          if (!b.dueDate) return -1;
          return new Date(a.dueDate) - new Date(b.dueDate);
        case 'priority':
          const priorityOrder = { high: 3, medium: 2, low: 1 };
          return priorityOrder[b.priority] - priorityOrder[a.priority];
        case 'created':
          return new Date(b.createdAt) - new Date(a.createdAt);
        default:
          return 0;
      }
    });

    return filteredTasks;
  }
}

3. DOM Manipulation and Rendering

// Render tasks to the DOM
renderTasks() {
  const taskList = document.getElementById('task-list');
  const filteredTasks = this.getFilteredTasks();

  taskList.innerHTML = '';

  if (filteredTasks.length === 0) {
    taskList.innerHTML = `
      <div class="empty-state">
        <h3>No tasks found</h3>
        <p>Add a new task to get started!</p>
      </div>
    `;
    return;
  }

  filteredTasks.forEach(task => {
    const taskElement = this.createTaskElement(task);
    taskList.appendChild(taskElement);
  });

  this.updateTaskStats();
}

// Create individual task element
createTaskElement(task) {
  const taskEl = document.createElement('div');
  taskEl.className = `task-item ${task.completed ? 'completed' : ''} ${task.isOverdue() ? 'overdue' : ''}`;
  taskEl.dataset.taskId = task.id;

  const daysUntilDue = task.getDaysUntilDue();
  const dueDateDisplay = task.dueDate ? 
    `<span class="due-date ${task.isOverdue() ? 'overdue' : ''}">
      ${task.isOverdue() ? 'Overdue' : daysUntilDue === 0 ? 'Due today' : `${daysUntilDue} days left`}
    </span>` : '';

  taskEl.innerHTML = `
    <div class="task-content">
      <div class="task-header">
        <input type="checkbox" class="task-checkbox" ${task.completed ? 'checked' : ''}>
        <h3 class="task-title">${task.title}</h3>
        <span class="task-priority priority-${task.priority}">${task.priority.toUpperCase()}</span>
      </div>
      <p class="task-description">${task.description}</p>
      <div class="task-meta">
        <span class="task-category">${task.category}</span>
        ${dueDateDisplay}
      </div>
    </div>
    <div class="task-actions">
      <button class="btn btn-sm btn-secondary edit-task">Edit</button>
      <button class="btn btn-sm btn-danger delete-task">Delete</button>
    </div>
  `;

  return taskEl;
}

4. Event Handling

// Initialize all event listeners
initializeEventListeners() {
  // Task form submission
  document.getElementById('task-form').addEventListener('submit', (e) => {
    e.preventDefault();
    this.handleTaskSubmission(e.target);
  });

  // Filter buttons
  document.querySelectorAll('.filter-btn').forEach(btn => {
    btn.addEventListener('click', (e) => {
      document.querySelectorAll('.filter-btn').forEach(b => b.classList.remove('active'));
      e.target.classList.add('active');
      this.filterTasks(e.target.dataset.filter);
    });
  });

  // Sort dropdown
  document.getElementById('sort-select').addEventListener('change', (e) => {
    this.currentSort = e.target.value;
    this.renderTasks();
  });

  // Search functionality
  document.getElementById('search-input').addEventListener('input', (e) => {
    this.searchTasks(e.target.value);
  });

  // Task list event delegation
  document.getElementById('task-list').addEventListener('click', (e) => {
    const taskItem = e.target.closest('.task-item');
    if (!taskItem) return;

    const taskId = taskItem.dataset.taskId;

    if (e.target.classList.contains('task-checkbox')) {
      this.toggleTask(taskId);
    } else if (e.target.classList.contains('edit-task')) {
      this.editTask(taskId);
    } else if (e.target.classList.contains('delete-task')) {
      this.confirmDeleteTask(taskId);
    }
  });
}

5. Advanced Features

// Search functionality
searchTasks(query) {
  if (!query.trim()) {
    this.renderTasks();
    return;
  }

  const searchResults = this.tasks.filter(task => 
    task.title.toLowerCase().includes(query.toLowerCase()) ||
    task.description.toLowerCase().includes(query.toLowerCase()) ||
    task.category.toLowerCase().includes(query.toLowerCase())
  );

  this.renderFilteredTasks(searchResults);
}

// Task statistics
updateTaskStats() {
  const totalTasks = this.tasks.length;
  const completedTasks = this.tasks.filter(task => task.completed).length;
  const overdueTasks = this.tasks.filter(task => task.isOverdue()).length;

  document.getElementById('total-tasks').textContent = totalTasks;
  document.getElementById('completed-tasks').textContent = completedTasks;
  document.getElementById('overdue-tasks').textContent = overdueTasks;
}

// Notification system
showNotification(message, type = 'info') {
  const notification = document.createElement('div');
  notification.className = `notification notification-${type}`;
  notification.textContent = message;

  document.body.appendChild(notification);

  // Trigger animation
  setTimeout(() => notification.classList.add('show'), 100);

  // Remove notification after 3 seconds
  setTimeout(() => {
    notification.classList.remove('show');
    setTimeout(() => notification.remove(), 300);
  }, 3000);
}

🚀 Initialization and Usage

// Initialize the task manager when DOM is loaded
document.addEventListener('DOMContentLoaded', () => {
  const taskManager = new TaskManager();

  // Make it globally accessible for debugging
  window.taskManager = taskManager;

  console.log('Task Manager initialized successfully!');
});

🎨 Key JavaScript Concepts Demonstrated

1. ES6+ Classes

We use modern class syntax to organize our code into reusable, maintainable components.

2. Array Methods

Extensive use of filter(), map(), find(), sort(), and other array methods for data manipulation.

3. Local Storage

Persistent data storage using the browser's localStorage API.

4. Event Delegation

Efficient event handling using event delegation for dynamic content.

5. Template Literals

Clean string interpolation and multi-line strings for HTML generation.

6. Destructuring and Spread Operator

Modern JavaScript syntax for cleaner, more readable code.

🔧 Performance Optimizations

Event Delegation: Instead of adding listeners to each task, we use a single listener on the container.
Efficient Rendering: Only re-render when necessary and use document fragments for multiple DOM insertions.
Debounced Search: Implement debouncing for search functionality to improve performance.

// Debounced search implementation
const debounce = (func, wait) => {
  let timeout;
  return function executedFunction(...args) {
    const later = () => {
      clearTimeout(timeout);
      func(...args);
    };
    clearTimeout(timeout);
    timeout = setTimeout(later, wait);
  };
}

// Usage
const debouncedSearch = debounce((query) => {
  this.searchTasks(query);
}, 300);

🎯 What You've Learned

Building this task manager teaches you:

Object-Oriented Programming in JavaScript
DOM manipulation techniques
Event handling and delegation
Local storage for data persistence
Array methods for data processing
Modern JavaScript features (ES6+)
Performance optimization techniques

🚀 Next Steps

To extend this project, consider adding:

Drag and drop for task reordering
Task categories with color coding
Export/import functionality
Reminder notifications using the Notification API
Collaborative features with real-time sync
Progressive Web App capabilities

🎉 Conclusion

This task manager demonstrates the power of vanilla JavaScript for building interactive web applications. By understanding these core concepts, you'll be well-equipped to tackle more complex JavaScript projects and frameworks.

The complete source code is available on GitHub. Feel free to fork, modify, and make it your own!

What's your favorite JavaScript feature used in this project? Let me know in the comments below! 👇

Tags: #javascript #webdev #tutorial #programming #beginners

Python Programming

Darshil Mahraur — Thu, 26 Jun 2025 20:53:20 +0000

This is a blog post about Python programming. Please replace this with your actual content.

Building a Weather App: A Complete Guide to Weather APIs and Data Visualization

Darshil Mahraur — Thu, 26 Jun 2025 18:57:32 +0000

Building a Weather App: A Complete Guide to Weather APIs and Data Visualization

Weather applications are among the most popular and useful apps we use daily. Whether you're checking if you need an umbrella or planning a weekend trip, weather data plays a crucial role in our decision-making. In this comprehensive guide, we'll explore how to build a weather application from scratch using modern web technologies.

Why Build a Weather App?

Weather apps are excellent projects for developers because they involve:

API Integration: Working with real-time data from weather services
Data Visualization: Displaying complex information in user-friendly formats
Geolocation: Understanding location-based services
Responsive Design: Creating apps that work across different devices
Real-time Updates: Handling dynamic data that changes frequently

Popular Weather APIs

1. OpenWeatherMap API

OpenWeatherMap is one of the most popular choices for developers:

Free tier: 1,000 calls/day
Features: Current weather, forecasts, historical data
Global coverage: Worldwide weather data
Documentation: Excellent API documentation

2. WeatherAPI

A developer-friendly alternative:

Free tier: 1 million calls/month
Features: Real-time weather, forecasts, astronomy data
JSON/XML: Multiple response formats
Easy integration: Simple REST API

3. AccuWeather API

Enterprise-grade weather data:

High accuracy: Professional weather forecasting
Limited free tier: 50 calls/day
Advanced features: Severe weather alerts, air quality data

Building Your First Weather App

Let's create a simple weather app using JavaScript and the OpenWeatherMap API.

Step 1: HTML Structure

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Weather App</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <div class="container">
        <h1>🌤️ Weather App</h1>
        <div class="search-container">
            <input type="text" id="cityInput" placeholder="Enter city name...">
            <button id="searchBtn">Search</button>
        </div>
        <div class="weather-container" id="weatherContainer">
            <!-- Weather data will be displayed here -->
        </div>
    </div>
    <script src="script.js"></script>
</body>
</html>

Step 2: CSS Styling

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

body {
    font-family: 'Arial', sans-serif;
    background: linear-gradient(135deg, #74b9ff, #0984e3);
    min-height: 100vh;
    display: flex;
    align-items: center;
    justify-content: center;
}

.container {
    background: rgba(255, 255, 255, 0.95);
    padding: 30px;
    border-radius: 15px;
    box-shadow: 0 15px 35px rgba(0, 0, 0, 0.1);
    min-width: 400px;
}

.search-container {
    display: flex;
    margin-bottom: 30px;
}

#cityInput {
    flex: 1;
    padding: 12px;
    border: 1px solid #ddd;
    border-radius: 5px 0 0 5px;
    font-size: 16px;
}

#searchBtn {
    padding: 12px 20px;
    background: #0984e3;
    color: white;
    border: none;
    border-radius: 0 5px 5px 0;
    cursor: pointer;
    font-size: 16px;
}

.weather-info {
    text-align: center;
}

.temperature {
    font-size: 4em;
    font-weight: bold;
    color: #2d3436;
    margin: 20px 0;
}

.description {
    font-size: 1.5em;
    color: #636e72;
    margin-bottom: 20px;
}

.details {
    display: grid;
    grid-template-columns: repeat(2, 1fr);
    gap: 15px;
    margin-top: 20px;
}

.detail-item {
    background: #f8f9fa;
    padding: 15px;
    border-radius: 8px;
    text-align: center;
}

Step 3: JavaScript Logic

const API_KEY = 'YOUR_API_KEY_HERE'; // Get from OpenWeatherMap
const API_URL = 'https://api.openweathermap.org/data/2.5/weather';

document.getElementById('searchBtn').addEventListener('click', getWeather);
document.getElementById('cityInput').addEventListener('keypress', function(e) {
    if (e.key === 'Enter') {
        getWeather();
    }
});

async function getWeather() {
    const city = document.getElementById('cityInput').value.trim();

    if (!city) {
        alert('Please enter a city name');
        return;
    }

    try {
        const response = await fetch(`${API_URL}?q=${city}&appid=${API_KEY}&units=metric`);

        if (!response.ok) {
            throw new Error('City not found');
        }

        const data = await response.json();
        displayWeather(data);

    } catch (error) {
        alert('Error fetching weather data: ' + error.message);
    }
}

function displayWeather(data) {
    const weatherContainer = document.getElementById('weatherContainer');

    const weatherHTML = `
        <div class="weather-info">
            <h2>${data.name}, ${data.sys.country}</h2>
            <div class="temperature">${Math.round(data.main.temp)}°C</div>
            <div class="description">${data.weather[0].description}</div>
            <div class="details">
                <div class="detail-item">
                    <strong>Feels like</strong><br>
                    ${Math.round(data.main.feels_like)}°C
                </div>
                <div class="detail-item">
                    <strong>Humidity</strong><br>
                    ${data.main.humidity}%
                </div>
                <div class="detail-item">
                    <strong>Wind Speed</strong><br>
                    ${data.wind.speed} m/s
                </div>
                <div class="detail-item">
                    <strong>Pressure</strong><br>
                    ${data.main.pressure} hPa
                </div>
            </div>
        </div>
    `;

    weatherContainer.innerHTML = weatherHTML;
}

// Get user's location weather on page load
window.addEventListener('load', () => {
    if (navigator.geolocation) {
        navigator.geolocation.getCurrentPosition(
            position => {
                const { latitude, longitude } = position.coords;
                getWeatherByCoords(latitude, longitude);
            },
            error => {
                console.log('Geolocation error:', error);
            }
        );
    }
});

async function getWeatherByCoords(lat, lon) {
    try {
        const response = await fetch(`${API_URL}?lat=${lat}&lon=${lon}&appid=${API_KEY}&units=metric`);
        const data = await response.json();
        displayWeather(data);
    } catch (error) {
        console.log('Error fetching weather by coordinates:', error);
    }
}

Advanced Features to Consider

1. Weather Forecasts

Extend your app to show 5-day forecasts:

const FORECAST_URL = 'https://api.openweathermap.org/data/2.5/forecast';

async function getForecast(city) {
    const response = await fetch(`${FORECAST_URL}?q=${city}&appid=${API_KEY}&units=metric`);
    const data = await response.json();

    // Process forecast data
    const dailyForecasts = data.list.filter((item, index) => index % 8 === 0);
    return dailyForecasts;
}

2. Weather Maps

Integrate weather maps using services like:

OpenWeatherMap Maps
Mapbox with weather layers
Google Maps with weather overlays

3. Push Notifications

Add weather alerts and daily forecasts:

// Request notification permission
if ('Notification' in window) {
    Notification.requestPermission().then(permission => {
        if (permission === 'granted') {
            // Schedule weather notifications
            scheduleWeatherNotifications();
        }
    });
}

4. Offline Support

Implement service workers for offline functionality:

// Register service worker
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/sw.js')
        .then(registration => console.log('SW registered'))
        .catch(error => console.log('SW registration failed'));
}

Best Practices

1. API Key Security

Never expose API keys in client-side code
Use environment variables
Implement server-side proxy for API calls

2. Error Handling

Handle network failures gracefully
Provide meaningful error messages
Implement retry mechanisms

3. Performance Optimization

Cache weather data to reduce API calls
Implement debouncing for search inputs
Use lazy loading for forecast data

4. User Experience

Show loading states during API calls
Implement smooth transitions
Provide fallback content for errors

Conclusion

Building a weather app is an excellent way to learn modern web development concepts while creating something genuinely useful. From basic API integration to advanced features like push notifications and offline support, weather apps offer countless opportunities for learning and improvement.

The key to a successful weather app lies in:

Reliable data sources: Choose APIs with good uptime and accuracy
Intuitive design: Make weather information easy to understand at a glance
Performance: Ensure fast loading times and smooth interactions
Accessibility: Design for users with different needs and devices

Start with a simple implementation and gradually add features as you become more comfortable with the concepts. Remember that the best weather apps are those that solve real problems for real users.

Resources

Happy coding! 🌦️

Convert http to https in AWS

Darshil Mahraur — Sat, 16 Nov 2024 12:13:25 +0000

Upgrade Your EC2 Instance: A Step-by-Step Guide to Securing Your Site with HTTPS!

Overview

To secure the public URL provided by a load balancer when connecting to an EC2 instance within the same VPC, it’s crucial to follow a structured approach. Start by acquiring a registered domain name from a trusted provider like GoDaddy. Next, configure your EC2 instance to function behind an Application Load Balancer (ALB) within the same VPC. Upload your domain to AWS Certificate Manager to obtain a verified SSL/TLS certificate. Finally, integrate this certificate into Route 53 and map it to your load balancer. This setup not only secures your connection but lays the foundation for seamless and reliable traffic management. Let’s dive deeper into the steps—you’re just a few clicks away from an airtight setup!

Prerequisite

Domain Name Registration
Obtain a domain name from a trusted third-party provider say GoDaddy for mapping your load balancer's public URL.
Integration with ALB
Ensure your EC2 instance is connected to an Application Load Balancer within the same VPC to manage traffic securely and efficiently.
You can attain this by referring to this Linkedin post.

Steps

Step 1: Verify Your Domain with AWS Certificate Manager

Go to AWS console and select ACM.
Request a new certificate and keep it public.

Here enter your domain name and keep the setting as selected below. By selecting DNS validation you will get the cname and and it's value.

Copy paste the cname and value to Go Daddy DNS Records. By doing this the certificate will get verified in few minutes.

Once your certificate is successfully issued, the AWS Certificate Manager (ACM) process is complete.

Step 2: Configure Route 53 and Update Nameservers in GoDaddy

Go to AWS Route53 and create your hosted zone with your domain and keep it public zone.

Once the zone is created you will get NS records as shown.

Go to Go Daddy and select nameservers and then change nameservers.
Select the option 'I'll use my own nameservers' and paste the nameserver we got previously from Route53.

Once this is done then your Go Daddy will no more responsible for managing your nameservers. It will look something like this.

Once this is successfully done, the AWS Route53 process is complete.

General Knowledge

Nameservers are part of the Domain Name System (DNS) that translate domain names (like example.com) into IP addresses that computers use to identify each other. They are essential because they direct internet traffic to the correct server, ensuring users can access your website or application seamlessly.
Amazon Route 53 is a scalable DNS web service that connects user requests to internet resources like websites or applications. It manages domain names, routes traffic efficiently, and integrates with AWS services to provide secure, reliable, and highly available routing.

Step 3: Connect your Route53 to Application load balancer.

Create a A record for your domain to connect your Route53 to Application Load Balancer and select 'switch to wizard'

Select simple routing and proceed.

Select 'Define Simple Record' and a pop up menu will appear like this.

Select Application and Classic Load Balancer , the region where it is located and choose the load balancer you have created previously.

Once completed, you'll be able to connect your application using your IP address, but only via HTTP, not HTTPS.

Step 4: Final Step (Make it Https)

Go to Certificate Manager , select your issued certificate and click 'Create record in Route53'. This will link a cname record of this certificate with Route53.

Now link the certificate to the load balancer. Go to your load balancer and add a listener for HTTPS:443.
Under Secure listener settings link your issued certificate from ACM.

Once completed, you'll be able to connect your application using HTTPS.

Conclusion

Congratulations! 🎉 You have successfully completed the HTTP to HTTPS tutorial. Your website is now securely encrypted, providing a safer browsing experience for your users. Great job!

Additionals

Make sure your security groups inbound rules are accepting https traffic.
You can redirect your http traffic to https in the rules section.

New here ,

Darshil Mahraur — Sun, 28 Apr 2024 19:50:42 +0000

Hello everyone , I am new to this platform.