DEV Community: Puneet Khandelwal

Scalable vs. Sustainable: The Architecture Trap

Puneet Khandelwal — Thu, 24 Sep 2026 18:34:01 +0000

Engineering culture has a fetish for hyper-scale. We design database schemas, microservice meshes, and asynchronous ingestion pipelines assuming traffic will mimic a tech giant on launch day. Yet, for most teams building internal tools, developer tools, or niche SaaS products, chasing pure scalability is a disguised form of self-sabotage. It introduces infrastructure complexity that bleeds engineering velocity and inflates cloud bills before the product finds a repeatable market fit.

Scalability means the system handles increased load gracefully by throwing compute, sharding, or replication at the bottleneck. Sustainability means the system requires minimal maintenance, predictable compute footprints, and straightforward debugging cycles when things break at three in the morning. When you optimize exclusively for scale, you trade operational simplicity for a hypothetical future that might never arrive.

Consider how this plays out in the data layer. A scalable approach demands a distributed database with eventual consistency, read replicas, and complex caching tiers. A sustainable approach uses a single relational database instance with proper indexes and connection pooling. The former requires constant tuning, careful migration strategies, and deep domain expertise in distributed systems. The latter lets a single developer sleep through the night while handling thousands of requests per second on modest hardware.

python

The scalable approach: distributed, asynchronous, complex

async def ingest_event(event_payload):
await message_queue.publish("events_topic", event_payload)
# Requires background workers, dead-letter queues, and monitoring

The sustainable approach: synchronous, bounded, transparent

def ingest_event(db_connection, event_payload):
with db_connection.cursor() as cursor:
cursor.execute(
"INSERT INTO events (payload) VALUES (%s)",
(json.dumps(event_payload),)
)
# Fails fast, logs directly, easy to reason about

The code above illustrates the operational divide. The asynchronous queue scales horizontally across clusters, but it multiplies failure points. Network partitions, broker crashes, and serialization mismatches turn simple debugging sessions into archaeology digs. The synchronous insert is boring. It blocks, it fails locally, and it tells you immediately why the write failed.

This dynamic repeats itself in the AI and machine learning tooling space. Teams rush to deploy massive LLM orchestration frameworks, complex vector databases, and multi-agent loops for enterprise-grade readiness out of the gate. Yet, many of these systems collapse under their own weight because the operational overhead outweighs the business value. A simpler pipeline processing text locally with deterministic fallback logic beats a sprawling agentic architecture on both cost and reliability.

One non-obvious implication of choosing sustainability over scalability is talent retention. Junior and mid-level engineers can read, debug, and improve a sustainable codebase without needing a PhD in distributed systems. When you build hyper-scale abstractions into a product with modest traffic, you create an internal barrier to entry. New hires spend months learning the idiosyncrasies of custom infrastructure instead of shipping features users pay for.

Build for the scale you have, plus a reasonable buffer for growth. Keep your dependency tree lean, favor boring technology stacks, and let your cloud bill dictate your architecture before your ambitions do. Scale is a luxury you buy with revenue, not a default setting you configure on day one.

Why Your North-Facing Bedroom Looks Gray (And How Paint Fixes It)

Puneet Khandelwal — Wed, 23 Sep 2026 18:27:44 +0000

If you've ever painted a room crisp white only to watch it turn a depressing shade of blue-gray, you already know how punishing north-facing light can be. That icy daylight strips the life right out of standard whites. Your freshly painted bedroom suddenly feels like an operating room.

Writing code teaches you to look at inputs and outputs. Interior design works the same way. The input here is raw sunlight hitting your windows, filtered and tinted blue from the northern sky. If your output is a cool white paint containing gray or green undertones, the math fails. You compound the chill instead of balancing it out.

Most people test paint swatches directly on an existing colored wall. That introduces background noise into your experiment. A better debugging method involves painting candidate swatches onto large poster boards and moving them around the room over 24 hours. You need to see how the paint reacts at dawn, midday, and twilight before committing to five gallons of it.

Warm whites with subtle yellow, cream, or beige undertones act like a software patch for this lighting problem. They absorb the aggressive blue bias of the room and bounce back a softer glow. Suddenly, the space feels intentional and cozy rather than sterile.

To master the variables of undertones and light reflectance values before you buy any cans, take a look at the guide on how to pick the perfect paint shade for a north-facing bedroom.

Fixing a gloomy room comes down to understanding the physics of your light source. Stop fighting the exposure and engineer your color choices around it. The results fall right into place.

Stop Using Tiny Rugs: The Math Behind Small Living Room Layouts

Puneet Khandelwal — Wed, 23 Sep 2026 15:42:15 +0000

Choosing a rug for a small living room feels a lot like managing memory allocation on a constrained machine. Go too big and you crash the layout. Go too small and the whole interface looks fragmented. Most people grab a standard postage-stamp rug and center it under the coffee table, wondering why the room suddenly feels cramped.

The single biggest design bug in small rooms is floating furniture. When your sofa sits entirely off the rug, it visually detaches from the rest of the space. This creates awkward negative zones that make the room feel disjointed. Treat your floor plan like a grid system where boundaries matter.

The standard for compact layouts relies on the 60 to 70 percent rule. Your rug should span roughly 60 to 70 percent of the total seating footprint. The front legs of your sofa need to anchor directly onto the fabric. This subtle overlap forces the eye to scan across a unified plane, creating an illusion of depth that standard sizing misses.

Measuring the space requires the same precision you apply to hardware specs. Start by noting the exact perimeter, but pay special attention to swing clearances for doors and heating vents. If a door snags on a high-pile wool rug every time it opens, your layout fails the basic usability test.

Drafting a quick floor sketch before buying anything saves you from expensive returns. Map out your primary seating dimensions, add your buffer zones, and test the proportions physically using painter tape on the floor. Seeing the physical boundary in real life prevents the mistake of buying a rug that looks fine in a massive warehouse showroom but overwhelms a modest apartment.

Check out the complete guide on how to choose the perfect rug size for a small living room for more space-saving layouts and exact sizing frameworks.

Getting proportions right in a small footprint comes down to discipline and measuring twice. Nail the baseline math, and styling the rest of the room falls into place.

Data Engineering for the Streets: Fixing Civic Infrastructure

Puneet Khandelwal — Tue, 22 Sep 2026 12:32:32 +0000

When a water main bursts or a pothole swallows a bicycle wheel, the failure isn't just physical. It's a data failure. We spend our days optimizing high-throughput trading feeds or user tracking loops, yet our local municipal infrastructure runs on brittle spreadsheets and legacy databases that refuse to talk to each other. Building pipelines for civic systems means dropping the obsession with millisecond latency. You prioritize fault tolerance and real-world data lineage instead.

Most municipal open data portals publish static CSV dumps on erratic schedules. If you want to build a functional tool for your community—like an interactive map tracking lead pipe replacements or ambulance response times—you have to pull that messy data into a reliable warehouse. The engineering hurdle isn't scaling to millions of requests per second. You're dealing with schema drift, missing GPS coordinates, and historical records that change overnight without warning.

Let's look at a practical pattern for cleaning up unstructured municipal complaint logs. Strict typing saves downstream pipelines from silent failures when you process raw CSV feeds from city agencies. Here's a Python snippet using standard libraries to normalize inconsistent street addresses before they hit your spatial database:

import re

def normalize_street_address(raw_address):
if not raw_address:
return None
cleaned = raw_address.upper().strip()
cleaned = re.sub(r'\bST\b', 'STREET', cleaned)
cleaned = re.sub(r'\bAVE\b', 'AVENUE', cleaned)
cleaned = re.sub(r'\bRD\b', 'ROAD', cleaned)
cleaned = re.sub(r'\s+', ' ', cleaned)
return cleaned

raw_logs = ['123 Main St.', '456 Broadway Ave', ' 789 Park Rd ']
normalized = [normalize_street_address(addr) for addr in raw_logs]
print(normalized)

Why does this matter? Resource allocation follows the data. If a neighborhood has language barriers or low digital literacy, residents file fewer formal complaints through official portals. A naive pipeline treats low complaint volume as low need. A good engineer joins the data against demographic layers or census tracts to spot underserved areas where infrastructure rots silently beneath the asphalt.

This points to a blind spot in our industry. When civic tech projects crash and burn, post-mortems usually blame red tape or tight budgets. The root cause is often technical arrogance. Developers try to drop shiny, complex architectures on agencies that lack the staff to maintain them. The winning civic data projects rely on boring, transparent technology. If your pipeline breaks, a municipal worker with basic SQL skills needs to trace the transformation logic without a background in distributed systems.

Fixing our cities means treating civic data with the same rigorous engineering standards we apply to commercial software. When we write robust ingestion scripts, enforce data contracts with city agencies, and build transparent dashboards, we give communities the factual foundation they need to hold local governments accountable. The code we write locally shapes whether public services reach the people who need them.

Stop Building LLM Wrappers That Die on Production Edge Cases

Puneet Khandelwal — Mon, 21 Sep 2026 09:32:01 +0000

The era of the simple system prompt and a raw API call is over. If your SaaS relies on firing off a request to an LLM endpoint and hoping the JSON comes back clean, your error monitoring is already screaming. Engineering teams are ditching fragile prompt chains for robust state machines that treat language models as unreliable probabilistic components.

The core issue is simple. Developers trained on traditional REST APIs expect binary outcomes. Code compiles or throws a typed exception. A database query returns records or times out. But language models operate on continuous probability distributions. They hallucinate keys, drop closing braces, and occasionally answer in fluent French because the system prompt drifted. Building a reliable product on top of this requires defensive architecture.

Let's look at a practical pattern separating production-grade AI code from hobbyist scripts. Instead of trusting the model to return valid structured data on the first try, wrap the interaction in a feedback loop with runtime schema validation. If the output fails your parser, feed the exact validation error back to the model as a correction prompt.

import json
from pydantic import BaseModel, ValidationError

class UserAction(BaseModel):
 action: str
 confidence: float

def get_validated_action(prompt: str, max_retries: int = 3) -> UserAction:
 current_prompt = prompt
 for attempt in range(max_retries):
 try:
 raw_response = call_llm(current_prompt)
 data = json.loads(raw_response)
 return UserAction(**data)
 except (ValidationError, json.JSONDecodeError) as e:
 if attempt == max_retries - 1:
 raise
 current_prompt = f"Previous output failed validation: {e}. Fix the JSON and try again."

This pattern changes how you cost out AI features. Every retry is a token cost multiplier. When latency spikes and API bills double, you stop blaming the model provider and start fixing your validation loop. The competitive moat for developer tools isn't access to better foundational models. The moat is how cleanly you sandbox, validate, and constrain them.

The non-obvious implication is huge. As inference costs drop and model capabilities flatten out, the value moves entirely to the state machine orchestrating the execution graph. Companies building proprietary orchestration layers capture more margin than companies training raw weights. If your developer workflow lacks robust output schemas and automated self-healing loops, you're building technical debt disguised as artificial intelligence.

Designing a UI for a Productivity App That Actually Helps

Puneet Khandelwal — Sat, 19 Sep 2026 18:34:37 +0000

We all build productivity apps that paradoxically destroy our productivity.

Every time I open a task manager with three columns, thirty tag colors, and an ambient sound generator, I spend twenty minutes organizing the interface instead of doing the actual work. As engineers, we love complex systems. We treat user interfaces like playgrounds for state management, packing every screen with notifications, progress bars, and gamified streaks. The result mimics the exact corporate chaos we try to escape.

Real productivity software needs to do the opposite. It needs to get out of the way. Lower cognitive friction, not maximize screen time. If a user deciphers an icon legend just to check off a grocery item, the design fails.

Let's look at state and layout in a minimalist task component. Skip heavy component libraries loading dozens of unnecessary DOM nodes. A clean implementation relies on direct feedback and simple conditional rendering. Here's a stripped-down React pattern focusing on intent without visual noise:

import { useState } from 'react';

export function FocusTask({ initialTask }) {
 const [isComplete, setIsComplete] = useState(initialTask.completed);

 return (
 <div 
 onClick={() => setIsComplete(!isComplete)}
 style={{
 opacity: isComplete? 0.4 : 1,
 textDecoration: isComplete? 'line-through' : 'none',
 cursor: 'pointer',
 padding: '1rem',
 transition: 'opacity 0.2s ease'
 }}
 >
 {initialTask.text}
 </div>
 );
}

Notice what's missing here. No priority badges, no estimated time counters, no subtask dropdowns. Just the task and the action. Remove the clutter and users focus on execution instead of administration.

Shift design philosophy from engagement to completion. Metrics like daily active hours prove toxic in productivity tools. If a user spends two hours inside your app, they probably failed to get actual work done. Success looks like a blank screen and a closed laptop.

Next time you sketch a new feature or refactor a dashboard, check if you're adding value or just noise. Strip away gradients, hide analytics until requested, and design for the moment the user logs off.

Shipping Democracy on Linux: What Building a Ballot System Taught Me

Puneet Khandelwal — Fri, 18 Sep 2026 18:22:38 +0000

When you write code for a municipal ballot server, a segfault isn't just a bug. It's a constitutional crisis waiting to happen.

Last season, our engineering collective took on the task of deploying an open-source ranked-choice voting prototype for a local civic district. We thought the hard part would be the cryptography. We were wrong. The hard part was wrestling the Linux kernel, systemd states, and strict hardware constraints into something that a skeptical board of elections could audit without needing a computer science degree.

Developers love abstraction. We build microservices, spin up containers, and abstract away the metal until the operating system feels like an infinite playground. But public infrastructure doesn't care about your abstraction layers. When we deployed our initial daemon on a hardened Debian distribution, we hit our first real-world wall: ephemeral storage. Most cloud architectures rely on ephemeral disks and auto-scaling groups. Voting machines, or the servers tallying their outputs, require determinism. If a node drops, the state must recover instantly, perfectly, and without phoning home to a proprietary telemetry server.

We stripped our stack down to the bare essentials. No Kubernetes orchestration layer adding unnecessary network overhead. Just systemd managing a statically compiled Rust binary communicating directly with a local SQLite instance mounted on encrypted disk partitions. Every state transition had to be written to an append-only log that could be read by a parish clerk holding a flashlight and a printed hash manifest.

Here is a snippet of the core state machine logic we used to ensure votes are processed sequentially without race conditions:

use std::sync::mpsc::{sender, receiver};
use std::fs::OpenOptions;
use std::io::Write;

pub struct BallotLedger {
 log_path: String,
}

impl BallotLedger {
 pub fn record_vote(&self, encrypted_vote: &[u8]) -> Result<(), std::io::Error> {
 let mut file = OpenOptions::new()
.create(true)
.append(true)
.open(&self.log_path)?;

 file.write_all(encrypted_vote)?;
 file.sync_all()?;
 Ok(())
 }
}

Notice that sync_all call. In standard web development, writing to disk asynchronously is fine for performance. In civic tech, if the power cuts out the millisecond a voter hits submit, that write must be on the physical platter or flash chip before the UI renders success. Performance optimization took a back seat to durability.

Another harsh lesson was dependency management. Developers pull in hundreds of crates or npm packages with a single command. For a government contract, every third-party dependency is an attack surface and an audit liability. We spent three weeks auditing our dependency tree, eventually cutting out all external network libraries entirely. If the system can't talk to the internet, it can't be exfiltrated. Air-gapping forces you to write cleaner, more self-contained code.

The deployment taught us that civic technology is fundamentally an exercise in empathy. We spent days arguing about cryptographic blinding factors, but the real breakthrough came when we watched a non-technical poll worker interact with our command-line recovery script during a dry run (our notes). If the humans operating the hardware don't understand what the machine is telling them, the technology has already failed.

We need more engineers building public infrastructure, but we have to leave our Silicon Valley habits at the door. Design your next system assuming failure means losing the public trust instead of just losing a user session.

Stop Chasing Pristine Architecture Books

Puneet Khandelwal — Thu, 17 Sep 2026 15:34:20 +0000

Clean architecture books sell a fantasy. They show you a pristine domain layer that sits completely apart from databases, third-party APIs, and production mess. You read about hexagonal ports and adapters and feel a sudden urge to rewrite your entire backend. Don't do it.

Most engineering literature optimizes for day-one codebase elegance instead of day-four-hundred team velocity. Textbook systems introduce abstraction layers that only exist to satisfy purist design patterns. You write five interface classes for a single database table that will never change its backing store.

Real-world software engineering manages entropy. Systems fail because requirements shift, traffic spikes, and engineers quit. A heavily abstracted architecture makes tracing a request from the HTTP handler down to the SQL query painful. New hires jump through ten files just to understand a single function.

Test this with an LLM. Ask for a clean architecture template and it generates all the boilerplate factories, repositories, and dependency injection containers you want. Ask it to fix a production bug under pressure and watch what happens. That indirection slows down human and machine debugging alike.

Optimize for changeability instead of architectural purity. Write code that's easy to delete and rewrite. Monoliths with clear module boundaries beat distributed microservices by eliminating network latency and weird failure modes. If your business logic ties directly to your framework, but your team ships features twice as fast, you're winning. Framework lock-in is cheap rent for shipping product value early.

Here is a simple rule for your next service. If a design pattern demands three new files just to pass a string from a controller to a database, throw it out. Keep database queries close to handlers until your scale forces you to split them. Premature decoupling is just as dangerous as premature optimization.

A healthy, fast-moving repo looks slightly messy from the outside. It has quick hacks from tight deadlines paired with solid automated tests that catch regressions. Stop worrying about looking like a software architecture textbook and build systems that survive reality.

Debugging Fitbit OAuth2 token expiration in lifestyle apps

Puneet Khandelwal — Wed, 16 Sep 2026 13:04:50 +0000

Most wellness apps break around midnight because nobody tests what happens when a third-party fitness API quietly revokes an old token. We spent three weeks building a step tracker integration before realizing our OAuth2 refresh flow swallowed error codes. Every time the access token expired after its standard validity window, the background sync job failed silently. Users opened dashboards to empty graphs and assumed the platform was broken.

The culprit was a mismatch between how the Fitbit authorization server signals an expired grant and how our Node.js backend caught exceptions. When an invalid token request hits their endpoint, it returns a precise status code along with a specific error body indicating the grant expired or got revoked entirely. Our initial error handler treated every 401 response as a simple signal to swap the refresh token for a new pair. But if a user revokes access from mobile privacy settings, or if the refresh token sits idle past its inactive expiration limit, that standard retry loop enters an infinite recursion of failed authorization attempts.

We fixed this by treating authentication state as a finite state machine rather than a simple database boolean. When a request returns an invalid grant error, the system must immediately invalidate the local session, flag the connection as severed, and trigger a friendly re-authentication prompt in the client interface. We wrote a lightweight middleware wrapper that intercepts outgoing API calls, checks local token timestamps, and preemptively refreshes credentials if they sit within a safety margin of expiration.

Here is a simplified pattern of how we structure that check before hitting provider endpoints:

async function ensureValidToken(userId) {
const tokenData = await database.getToken(userId);
const now = Date.now();

if (tokenData.expiresAt - now < 300000) {
try {
const freshTokens = await refreshFitbitToken(tokenData.refreshToken);
await database.saveToken(userId, freshTokens);
return freshTokens.accessToken;
} catch (error) {
if (error.code === 'invalid_grant') {
await database.clearToken(userId);
throw new AuthRevokedError('Please reconnect your fitness device.');
}
throw error;
}
}
return tokenData.accessToken;
}

Handling these edge cases changes how reliable your product feels. Users ignore OAuth specifications and grant types completely; they just want to see morning runs sync without opening developer tools. Build resilient boundaries around external APIs so your software feels like a dependable tool instead of a fragile script.

Stop Using Tiny Rugs: The Proportion Fix for Small Spaces

Puneet Khandelwal — Wed, 16 Sep 2026 12:26:56 +0000

Using a tiny rug in a small living room is the fastest way to make the space feel cramped. When a rug is too small, your furniture floats like an island. Interior designers use a basic math trick to fix this and make rooms look bigger.

Target the 60 to 70 percent rule. Your rug needs to cover roughly 60 to 70 percent of the seating area footprint. If your couch spans 80 inches, extend the rug 10 to 12 inches past each arm. This creates a boundary that expands the floor space visually.

Treat it like a CSS grid bug. If your container is too small, elements overflow and crowd each other. Give your furniture room to breathe by establishing proper padding on all sides. Another mistake is floating all furniture completely off the rug. Get at least the front legs of your sofa and armchairs resting on the fabric to tie the seating zone together.

Test sizes with blue painter's tape or string before buying anything (see writeup). Map the dimensions right on your floor. Walk around, open doors, and check if your coffee table fits inside the boundary. If the tape blocks a door swing or heating vent, scale down the numbers.

Mastering scale transforms a tight layout from cluttered to intentional. Measure twice and respect the grid.

Stop Using Tiny Rugs: The Proportion Math for Small Rooms

Puneet Khandelwal — Wed, 16 Sep 2026 09:21:46 +0000

Using a tiny rug in a small living room wrecks the space. It floats in the middle of the floor like a postage stamp and makes everything feel cramped. Most people just guess at dimensions.

Treat your furniture layout like a container element problem. When you write code, parent bounds dictate child elements. Interior design follows the exact same logic. Put a three-by-five rug in front of an eighty-inch sofa and you break the visual hierarchy. The rug needs to act as a boundary box containing your primary seating group.

Use the 60 to 70 percent rule. Your rug should span roughly 60 to 70 percent of the total seating area width. If your couch measures seventy-two inches across, get a rug that extends six to ten inches past each end. That overlap anchors the group and tricks the eye into seeing a wider room.

Another trap is keeping every furniture leg either fully on or fully off the rug. In cramped spaces, compromise works best. Put the front legs of your sofa and armchairs on the rug. Let the back legs sit on bare floor. You create a cohesive zone without swallowing up all the visible floor space.

Before you drop money on a non-returnable piece, lay blue painter's tape on your floor to mark the exact dimensions. Walk around the room. Open your doors. Test how the tape interacts with your walking paths. This prototyping step catches sizing errors before delivery day.

Why Our Open-Source Election Visualizer Collapsed Under Load

Puneet Khandelwal — Mon, 14 Sep 2026 18:39:07 +0000

When we launched our open-source campaign finance visualizer, we expected modest local traffic. We were wrong. Election night brought a surge of concurrent users refreshing the precinct map every second, and our database connection pool flatlined within minutes.

We love building civic tools that bring transparency to government spending. The frontend ran on React, the backend used Node.js containers, and everything pointed at a managed PostgreSQL instance. It looked clean in staging. It felt fast during dry runs with synthetic data. Local elections generate sudden, emotional spikes in public interest, though. When thousands of citizens hit the site simultaneously to check where candidate donations originated, our naive API design crumbled.

The primary failure point wasn't cloud compute limits. It was our data fetching strategy. Every incoming HTTP request triggered a complex JOIN across three large tables containing donor addresses, committee IDs, and transaction amounts. We assumed Postgres could handle the analytical queries in real time. We neglected to pre-aggregate the campaign totals into a materialized view.

Under load, these unindexed queries locked the transaction tables and caused timeouts across the entire application layer. The connection pool exhausted its slots, dropping incoming TCP handshakes. Citizens saw endless loading spinners instead of public data.

Fixing the bottleneck meant moving away from real-time relational queries for read-heavy public dashboards. We decoupled the write database from the read replicas, introduced Redis caching for hot endpoints, and shifted heavy aggregation tasks to a nightly cron job. Static JSON files generated during the build step now power the baseline UI. Live websockets only push incremental precinct updates now.

Civic software carries a unique public trust. When infrastructure fails during an active election cycle, it damages confidence in open data initiatives. Building for government transparency requires the same defensive engineering principles we apply to high-frequency trading or large-scale e-commerce.

If your civic tech stack cannot survive election night, the transparency it provides remains theoretical. We learned that engineering for the public sector means designing for the worst-case traffic distribution from day one. Scale testing with randomized load scripts is not optional when the public relies on your code to understand who funds their local representatives (field notes here).