DEV Community: Cheela Sathvik

Your Database Failover Doesn't Work. Ask Me How I Know.

Cheela Sathvik — Tue, 03 Feb 2026 14:00:00 +0000

Last year, our primary database went down during a critical traffic spike. We had failover configured. Or at least, we thought we did.

Our logic seemed solid enough on paper:

if (primary.isDown) {
  switchTo(replica);
}

Simple, right?

Wrong.

The primary wasn't "down" in the way our code expected. It wasn't refusing connections. It was just incredibly, painfully slow. Our manual health check—a simple ping—kept succeeding, but queries were timing out.

Because our health check didn't account for latency spikes, our application kept flapping between the primary and the replica. Connections piled up. The pool exhausted. The service stalled.

It wasn't a crash. It was a slow, painful death by race condition.

The fix? We wrote about 200 lines of manual "glue code" to handle:

Timeouts
Retries
Circuit breaking
Graceful failover

I got tired of seeing this same brittle, manual boilerplate in every service I worked on. So I decided to solve it once and for all.

Introducing OmniDB

OmniDB is a thin orchestration library for Node.js. It’s not a new database client. It doesn't try to replace Prisma, or Mongoose, or pg. It simply orchestrates the clients you already use.

It handles the hard stuff automatically:

✅ Real Health Checks: Checks that respect timeouts and latency, not just connectivity.
✅ Race-Condition-Free Failover: Atomic switching when things go wrong.
✅ Circuit Breakers: Built-in protection to stop cascading failures.
✅ Graceful Shutdowns: Ensuring connections close cleanly.

The Problem with "Do It Yourself"

Most developers (myself included) start with something like this:

// ❌ The DIY Trap
const primary = new Client(PRIMARY_URL);
const replica = new Client(REPLICA_URL);

let active = primary;

setInterval(async () => {
    try {
        await primary.ping();
        active = primary;
    } catch (e) {
        console.warn("Primary down, using replica");
        active = replica;
    }
}, 5000);

Why this breaks:

Flapping: If the primary is unstable, you switch back and forth effectively DDOSing yourself.
No Circuit Breaker: If the replica is also stressed, you'll hammer it until it breaks too.
Request Drops: Requests in flight during the switch often just fail.

The OmniDB Way

Here is how you solve that same problem with OmniDB. It’s about 20 lines of code, and it handles all the edge cases we missed above.

// ✅ With OmniDB
import { Orchestrator } from 'omni-db';

const db = new Orchestrator({
  connections: {
      primary: new Client(PRIMARY_URL),
      replica: new Client(REPLICA_URL)
  },
  failover: { primary: 'replica' }, // simple declarative routing
  healthCheck: {
    interval: '30s',
    timeout: '5s', // strict timeout for checks
    checks: {
      primary: async (c) => { await c.query('SELECT 1'); return true; },
      replica: async (c) => { await c.query('SELECT 1'); return true; }
    }
  }
});

await db.connect();

// Usage:
// Automatically uses 'primary'.
// If 'primary' is unhealthy, it routes to 'replica'.
const client = db.get('primary');

Resilience by Design

OmniDB doesn't just check if a server is there; it manages the lifecycle of your availability.

Circuit Breakers

If a database starts failing repeatedly, OmniDB opens the circuit. This stops your application from waiting on dead connections and allows the database time to recover. You can use the built-in simple breaker or bring your own robust solution like opossum or cockatiel.

Events

You shouldn't have to guess what your database is doing. OmniDB emits events for everything:

db.on('failover', ({ primary, backup }) => {
  alertOps(`🚨 Switched from ${primary} to ${backup}`);
});

db.on('recovery', ({ primary, backup }) => {
  console.log(`✅ Recovered ${primary}, switching back from ${backup}`);
});

Why Use OmniDB?

Zero Dependencies: Just the core library. No bloat.
Scalable: O(1) lookup performance, making it efficient even with hundreds of database shards/tenants.
Agnostic: Works with Prisma, Drizzle, Redis, MongoDB, Postgres, or any other client.
TypeScript Native: Full type inference. db.get('redis') returns a Redis client type.

Stop Writing Boilerplate

Infrastructure code should be boring. It should be standard. And it should work.

Stop wrestling with race conditions in your setInterval loops. Start orchestrating.

Check out the repo on GitHub:
👉 https://github.com/sathvikc/omni-db

If you've ever battled a "silent failure" in production, let me know in the comments. I'd love to hear your war stories.

Building a High-Performance Zip Puzzle: A Lume-JS Masterclass

Cheela Sathvik — Tue, 23 Dec 2025 19:50:18 +0000

If you’ve been on LinkedIn lately, you’ve likely seen the "Zip" puzzle. It’s a beautifully simple grid-based game where you connect numbers in a path. While the game looks simple, implementing it with high-performance reactivity, smooth visual feedback, and infinite background puzzle generation is a great test for any front-end toolset.

Live Demo: sathvikc.github.io/linkedin-zip-puzzle/
Source Code: github.com/sathvikc/linkedin-zip-puzzle
Lume-JS Website: sathvikc.github.io/lume-js/

The Challenge: Beyond Manual DOM Manipulation

In a game like Zip, every move triggers a waterfall of UI changes:

The cell you clicked becomes "active."
A "path dot" appears.
"Connector lines" must draw themselves between the current cell and the previous/next cells.
The "Cells Visited" counter increments.
Win detection checks if the grid is full.

Doing this manually with document.getElementById is a recipe for spaghetti code.

The Solution: Lume-JS & Ruthless Minimalism

Lume-JS is built on the philosophy of "Ruthless Minimalism." At under 2KB, it provides a Proxy-based reactivity system that is both intuitive and powerful. Unlike VDOM-heavy frameworks, Lume-JS performs surgical DOM updates, which is critical for a game where the UI state changes with every pixel of mouse movement.

1. The Reactive State (An "Antidote" to Spaghetti Code)

Everything in the game starts with a single state() object.

const gameState = state({
    path: [],
    cells: generateInitialGrid(),
    elapsedSeconds: 0
});

2. Surgical Reactivity vs. Virtual DOM

The magic happens in the rendering. Instead of re-rendering the whole board or diffing a heavy Virtual DOM, we use the repeat addon. Each cell gets its own reactive effect.

render: (cellData, el) => {
    effect(() => {
        const pathIdx = gameState.path.indexOf(cellData.index);
        el.classList.toggle('active', pathIdx !== -1);
    });
}

This ensures the browser does the absolute minimum work necessary. In a 6x6 grid, when you move your mouse, only a single cell's classes are updated. No reconciliation, no complex diffing—just raw performance.

3. Offloading the Brain: Infinite Puzzles via Web Workers

Generating a valid, solvable Zip puzzle is computationally expensive. To keep the UI at 60fps, I offloaded the "Brain" to a Web Worker using Comlink. This allows for infinite background generation—the game is already preparing your next puzzle while you're still connecting the dots on the current one.

Why Lume-JS? The "Go-Style" Frontend

In an era where front-end bundles are ballooning, Lume-JS proves that you don't need a massive runtime to build premium experiences. It gives you the "DX" (Developer Experience) of a major framework with the performance of vanilla JavaScript.

Whether you're building a viral puzzle game or a complex enterprise dashboard, Lume-JS is a reminder that sometimes, less truly is more.

Resources & Links

Play the Game: sathvikc.github.io/linkedin-zip-puzzle/
View the Source Code: github.com/sathvikc/linkedin-zip-puzzle
Learn Lume-JS: sathvikc.github.io/lume-js/
Join the Conversation: Catch me on LinkedIn where I talk about micro-libraries and web performance!

I Built a 2KB React Alternative That Uses Zero Custom Syntax

Cheela Sathvik — Sat, 29 Nov 2025 09:27:13 +0000

You know what's funny? We keep inventing new ways to do the same thing: make HTML dynamic.

React gave us JSX. Vue gave us v-bind. Alpine gave us x-data. Svelte gave us its own template syntax. Each one reinvented how we write HTML, then asked us to install build tools to compile it back into... HTML and JavaScript.

What if we just used HTML and JavaScript?

That's Lume.js. I just released version 1.0.0, and it's a bet that web standards are actually good enough.

TL;DR

Lume.js is a 2KB reactive framework that uses only standard HTML and JavaScript. No JSX, no custom syntax, no build step required. Just data-bind attributes and ES6 Proxies. It's 9-21x smaller than React/Vue/Alpine.

→ Try it in 30 seconds | GitHub | npm

The Entire API in 30 Seconds

Here's a two-way bound input:

HTML:

<div>
  <h1>Hello, <span data-bind="name"></span>!</h1>
  <input data-bind="name" placeholder="Type your name">
</div>

JavaScript:

import { state, bindDom } from 'lume-js';

const store = state({ name: 'World' });
bindDom(document.body, store);

That's it. No JSX. No v-model. No x-data. No compiler. Just data-bind, which has been valid HTML since 2008.

Type in the input? The span updates. Change store.name in your code? The input updates. It's reactive, it's two-way, and your HTML passes validation.

→ See it working live

Why This Exists

Here's the thing: 80% of websites don't need a framework. Vanilla JavaScript is powerful enough for most things. DOM manipulation? Easy. Event listeners? Simple. Animations with GSAP? Works great.

The one thing vanilla JS lacks is reactivity.

You can write element.textContent = count, but when count changes, you have to remember to update the element manually. You can build dynamic forms, but you end up with spaghetti code tracking which values changed and which DOM elements need updates.

That's the only real problem. Not the language. Not the DOM APIs. Just reactivity.

So I built Lume to solve that one problem. Now I can use vanilla JS with reactivity everywhere:

WordPress sites where I can't install a build pipeline
Shopify themes that just need a dynamic cart
GSAP animations driven by reactive state
Internal tools that don't need webpack

No framework. No build step. Just JavaScript with the one missing piece added back in.

Want to see real examples? Check out the Todo app and Tic-Tac-Toe.

What Makes This Different (And Why You Might Care)

It's small. Under 2KB gzipped for the core. That's smaller than most images on your page. React + ReactDOM is ~42KB. Vue 3 is ~18KB. Alpine.js is ~15KB. Lume is under 2KB.

It uses standards. data-* attributes are standard HTML5. Proxies are standard ES6. It works in HTML validators, screen readers, email templates, CMS themes—places where custom syntax breaks.

No build step. Drop it in via CDN and start coding. Want to use a bundler? Fine. Don't want to? Also fine. I built working examples in single HTML files because I could.

It's fast. No virtual DOM. No diffing. When you change store.count, it directly updates element.textContent. For most UIs, this is faster than frameworks that diff virtual trees.

What You Actually Get

Automatic dependency tracking:

import { effect } from 'lume-js';

effect(() => {
  console.log(`Total: ${store.price * store.quantity}`);
  // Re-runs automatically when price or quantity changes
});

Computed values:

import { computed } from 'lume-js/addons';

const total = computed(() => store.price * store.quantity);
console.log(total.value); // Cached, updates automatically

Efficient list rendering:

import { repeat } from 'lume-js/addons';

repeat(container, store, 'items', {
  key: item => item.id,
  render: (item, el) => {
    el.textContent = item.name;
  }
});
// Reuses DOM elements, faster than re-rendering

Microtask batching: Update the same property 10 times? The DOM updates once. Performance without thinking.

All of this in 2KB.

→ Play with these examples in the interactive playground

Where It Actually Works

Lume isn't meant to replace full frameworks for every scenario. If you need a complete application framework with extensive routing and complex state management, there are excellent options out there built for that.

Lume.js works when you need:

Reactivity on a mostly static site (blogs, marketing pages)
Dynamic forms without framework overhead
Something that works in WordPress, Shopify, or other restricted environments
Progressive enhancement (page works with JS disabled)
Prototypes where webpack feels like overkill

Think of it as Knockout.js for 2025. Simple, standards-based reactivity when you don't need a full framework.

Install & Try It Now

Via CDN (quickest way):

<script type="module">
  import { state, bindDom } from 'https://cdn.jsdelivr.net/npm/lume-js/src/index.js';

  const store = state({ count: 0 });
  bindDom(document.body, store);
</script>

<button onclick="store.count++">Clicked <span data-bind="count">0</span> times</button>

Via npm:

npm install lume-js

The website has:

Live playground - Test it in your browser
Step-by-step tutorials - Build a Todo app and Tic-Tac-Toe
Full API docs - Everything you need to know

→ Start building now

The Philosophy Behind It

Standards age better than frameworks. JavaScript frameworks change every few years. data-* attributes have been stable since 2008. ES6 Proxies since 2015. What you build with Lume today will probably work in browsers 10 years from now.

Explicit beats magic. Lume requires you to wrap nested objects in state() explicitly. Yeah, it's more typing. But you know exactly what's reactive. No surprises when performance tanks because the framework auto-wrapped your entire Redux store.

Small and complete beats large and comprehensive. I didn't add features to compete with React. I added the minimum needed for reactive UIs: state, bindings, effects, computed values, list rendering. If you need routing or global state management, use another library. Lume plays well with others.

What This Took

Six months of nights and weekends. I rewrote the core three times. The first version used manual subscriptions and was too verbose. The second used automatic tracking but leaked memory. The third got it right: automatic tracking with explicit cleanup.

I wrote 114 tests with full coverage. Built working examples (Todo app, Tic-Tac-Toe, multi-step forms). Made sure bundle size never exceeded 2KB. Set up a website with docs and interactive tutorials.

The hardest part? Figuring out what not to add. Every feature request meant more bytes. More API surface. More ways to use it wrong. I said no to routing, animations, transitions, form validation, internationalization. Not because they're bad, but because they'd make the core worse.

Lume does one thing: makes your HTML reactive. Everything else is optional addons or separate libraries.

What Happens Next

The core API is stable. No breaking changes planned. The repeat addon is marked experimental because I want to refine its API before locking it in, but it works and it's tested.

I'm considering addons for routing and form validation, but only if they stay small and standards-based. No scope creep.

Mostly, I want to see what people build. If you try Lume and it doesn't fit your use case, tell me why. If you build something cool, show me. If you find a bug, open an issue.

This is version 1.0 of a bet that JavaScript and HTML are good enough without reinventing them every two years.