DEV Community: Akash Pattnaik

From 5 Seconds to 50ms: How I Stopped Nuking My Database Every Time I Deleted an Order

Akash Pattnaik — Sat, 13 Jun 2026 08:54:04 +0000

My Dessert Shop Dashboard Was Choking on Its Own Data — Here's the Architecture That Fixed It

Next.js App Router · Supabase · PostgreSQL performance · Incremental rollup tables

The Scene: A Dashboard Loading Like It's On Dial-Up

Picture this: your admin dashboard is open. You want to check last week's sales. You click the date range.

Nothing.

Then a spinner. A long, existential spinner.

Five seconds later — if you're lucky — the numbers appear. Meanwhile, your database connection pool is gasping for air, your serverless function has basically taken a lunch break, and somewhere a Postgres row lock is just vibing, holding everything hostage.

That was the state of the analytics dashboard I built for a retail franchise kiosk system on Next.js App Router + Supabase. High-volume orders, complex JSON-stored item data, coupons, loyalty coins, packaging options — and every time the admin so much as glanced at the dashboard, the server started sweating.

Let me walk you through the disaster, the misguided fix I shipped anyway, and the architecture that actually solved it.

The Root Cause: Your Raw Table Is Not a Reporting Table

The first version of the analytics page was beautifully naive. Admin requests "last 30 days of revenue"? Sure — let's just:

Fetch every order in that date range from the orders table
Parse the JSONB column selected_items (nested arrays of items, quantities, toppings) for each row, in-memory, in a Next.js serverless function
Distribute order-level discounts proportionally across individual line items in real time (flat Rs. 50 off? Cool, now figure out what fraction of that hits each item after excluding toppings and packaging fees)
Aggregate everything into totals
Pray

The complexity here is genuinely O(N_orders). Thousands of orders → thousands of JSON parses → proportional discount math → exhausted connection pool → timeout → 😵

BEFORE: Every Dashboard Request

Admin requests 30-day report
         │
         ▼
┌─────────────────────────────────┐
│  Next.js Serverless Function    │
│                                 │
│  SELECT * FROM orders           │
│  WHERE created_at > 30 days ago │  ← Full table scan
│                                 │
│  for each order:                │
│    parse JSONB selected_items   │  ← Memory intensive
│    distribute discount          │  ← CPU intensive
│    aggregate metrics            │
└──────────────┬──────────────────┘
               │  2.5s – 5s
               ▼
         Dashboard UI
         (eventually)

Under peak traffic, it was worse. Multiple admins → multiple concurrent full-table aggregation jobs → DB connection pool exhausted → cascade of timeouts. The dashboard became a slot machine where the prize was "maybe you get data."

The Nuclear Rebuild: My First (Very Bad) Fix

Here's the part where I should have thought harder but instead shipped a /api/admin/rebuild-stats endpoint.

The logic: whenever something changes — an order deleted, a coupon adjusted — just rebuild all the aggregate stats from scratch.

The process was essentially:

Fetch all historical paid orders in batches of 1,000
Recalculate daily stats, hourly stats, product sales, user lifetime metrics — all in-memory
TRUNCATE the aggregate tables
Re-insert everything from scratch

This worked. For about two weeks, until the order count hit tens of thousands. Then a single admin deleting one duplicate order would trigger a multi-minute full rebuild, lock the DB, and make the dashboard completely unresponsive.

I had essentially built a manual VACUUM that punished me for routine housekeeping.

The Nuclear Rebuild (❌ Don't Do This)

Admin deletes 1 order
         │
         ▼
POST /api/admin/rebuild-stats
         │
         ▼
┌─────────────────────────────────┐
│  Fetch ALL orders in batches    │  ← O(N) reads
│  of 1,000                       │
│                                 │
│  Recalculate EVERYTHING:        │
│  - daily_stats                  │
│  - hourly_orders                │  ← Minutes of work
│  - product_sales                │
│  - user_stats                   │
│                                 │
│  TRUNCATE aggregate tables      │  ← Row locks everywhere
│  Re-insert entire dataset       │
└─────────────────────────────────┘
         │
         ▼
  Dashboard unusable during rebuild
  (scales linearly with order count 🪦)

The fix was worse than the disease. Time to actually solve this properly.

The Epiphany: Pre-Aggregate at Write Time, Not Read Time

The insight that changed everything is deceptively simple:

The best time to compute aggregates is when the data is created — not when someone asks for it.

Instead of running expensive aggregations on every dashboard read, maintain a set of flat rollup tables that mirror your aggregated state. Every write (order created, order deleted, order modified) updates these rollup tables incrementally and atomically.

Dashboard reads become trivial index scans on tiny tables. Writes stay O(1) regardless of historical data size.

The Rollup Schema

Four lightweight tables cover the entire analytics surface:

-- Daily-level counters for date-range reports
daily_stats (
  date, total_orders, total_revenue, 
  packaging_count, packed, discount_total
)

-- Hourly breakdown for kitchen load planning
hourly_orders (
  date, hour, order_count, revenue
)

-- Per-product sales performance
product_sales (
  date, product_id, quantity_sold, revenue
)

-- Customer lifetime value tracking
user_stats (
  user_id, total_orders, total_spent, last_visit
)

No joins. No JSON parsing. No discount math. Just numbers, already computed, waiting in indexed rows.

The Architecture Shift

AFTER: Dashboard Reads (New Architecture)

Admin requests 30-day report
         │
         ▼
┌─────────────────────────────────┐
│  SELECT SUM(total_revenue),     │
│         SUM(total_orders)       │
│  FROM daily_stats               │
│  WHERE date BETWEEN x AND y     │  ← Index scan on N_days rows
│                                 │
│  SELECT product_id,             │
│         SUM(quantity_sold)      │
│  FROM product_sales             │
│  WHERE date BETWEEN x AND y     │
└──────────────┬──────────────────┘
               │  < 100ms
               ▼
         Dashboard UI ✅

┌─────────────────────────────────────────────────────────────┐
│                    BEFORE vs. AFTER                         │
├─────────────────────┬───────────────────────────────────────┤
│ Metric              │ Before          │ After               │
├─────────────────────┼─────────────────┼─────────────────────┤
│ Dashboard load time │ 2.5s – 5s       │ < 100ms             │
│ Query complexity    │ O(N_orders)     │ O(N_days)           │
│ Order delete cost   │ O(N) full scan  │ O(1) decrement      │
│ DB connection load  │ Pool exhaustion │ Minimal             │
│ Serverless timeouts │ Frequent        │ Eliminated          │
└─────────────────────┴─────────────────┴─────────────────────┘

50× faster dashboard reads. Zero rebuild jobs. Database stability restored.

The Implementation: Incremental Reversals on Delete

The magic is in how writes interact with the rollups. Let's look at the delete path — the one that previously triggered the nuclear rebuild.

When an admin deletes an order, the endpoint (app/api/admin/orders/delete/route.ts) now does something surgical instead of catastrophic:

Step 1: Load the order's metadata before deleting it to calculate its exact net contributions.

Step 2: Atomically decrement every affected rollup row.

Step 3: Delete the raw order.

Here's the actual code for reverting daily stats and product sales:

// 1. Fetch the daily rollup row for this order's date
const { data: existingDaily } = await supabase
  .from("daily_stats")
  .select("*")
  .eq("date", dateStr)
  .single();

if (existingDaily) {
  const updatedCount = Math.max(0, existingDaily.total_orders - 1);
  const updatedRevenue = Math.max(0, existingDaily.total_revenue - netRevenue);

  if (updatedCount === 0 && updatedRevenue === 0) {
    // Clean up days that now have no data (keeps the table lean)
    await supabase.from("daily_stats").delete().eq("date", dateStr);
  } else {
    await supabase.from("daily_stats").update({
      total_orders: updatedCount,
      total_revenue: updatedRevenue,
      packaging_count: Math.max(
        0,
        existingDaily.packaging_count - (orderToDel.opted_for_packaging ? 1 : 0)
      ),
      packed: Math.max(0, existingDaily.packed - finalPackedCount),
      discount_total: Math.max(0, existingDaily.discount_total - discountAmount),
    }).eq("date", dateStr);
  }
}

// 2. Revert product-level sales — one UPDATE per line item
for (const item of adjustedItems) {
  const itemRevenue = item.itemTotal - (item.itemDiscount || 0);
  const itemPackaging =
    isFallbackPackaging || item.packaged ? item.quantity * 10 : 0;
  const totalItemRevenueWithPackaging = itemRevenue + itemPackaging;

  const { data: existingSale } = await supabase
    .from("product_sales")
    .select("*")
    .eq("date", dateStr)
    .eq("product_id", item.id)
    .single();

  if (existingSale) {
    const updatedQty = Math.max(0, existingSale.quantity_sold - item.quantity);
    const updatedRevenue = Math.max(
      0,
      existingSale.revenue - totalItemRevenueWithPackaging
    );

    if (updatedQty === 0 && updatedRevenue === 0) {
      await supabase.from("product_sales").delete().eq("id", existingSale.id);
    } else {
      await supabase.from("product_sales").update({
        quantity_sold: updatedQty,
        revenue: updatedRevenue,
      }).eq("id", existingSale.id);
    }
  }
}

Notice what's not happening here: no fetching of thousands of orders, no TRUNCATE, no full recalculation. Just a handful of targeted UPDATE statements touching exactly the rows that need to change.

The same pattern applies to every other rollup: hourly stats get a decrement on the specific (date, hour) row. Product sales get decremented per line item. User lifetime stats (total_orders, total_spent) get decremented, with a secondary query to reset last_visit to their next most recent order if this was their latest transaction. Even the loyalty coin ledger gets a compensatory admin_adjust event inserted — no rebuild, just a corrective entry.

Every operation is O(1) relative to historical data size. It doesn't matter if you have 100 orders or 100,000 orders. Deleting one still touches the same number of rollup rows.

One Important Caveat: Keep the Raw Table for Granular Queries

The rollup tables handle aggregated analytics efficiently, but they don't replace raw data entirely. Dynamic scanning on the orders table is still permitted — but only for narrow, highly-indexed single-day views where you need granular data: custom topping breakdowns, cash vs. UPI payment splits, per-transaction audit trails.

The rule of thumb: aggregate reads go to rollups, granular inspection goes to the raw table with tight date constraints and proper indexes.

Key Takeaways for Dashboard Builders

1. Your orders table is a ledger, not a reporting table.
Don't run analytics queries on it directly. Maintain separate, pre-aggregated rollup tables optimized purely for reads.

2. Materialized views are great — until you need incremental updates.
PostgreSQL's MATERIALIZED VIEW requires a full refresh (REFRESH MATERIALIZED VIEW) which has similar scalability problems to the nuclear rebuild under heavy write load. Custom rollup tables with incremental math give you more surgical control.

3. Move complexity to write time, not read time.
Admins reading a dashboard vastly outnumber the frequency of order mutations. A slightly more complex write path (a few extra UPDATE statements on delete) pays for itself thousands of times over in fast reads.

4. Math.max(0, ...) is your guard rail.
When doing decremental math on rollup counters, always clamp to zero. Out-of-order event processing or edge cases can produce negative counters, which will corrupt your data silently.

5. Clean up empty rollup rows.
When a decrement produces a row where every counter is zero, delete it. This keeps your rollup tables lean and your index scans fast.

6. The nuclear rebuild is a trap.
A full-rebuild endpoint feels like a safe escape hatch. It's actually a time bomb — completely benign at 500 rows, catastrophic at 50,000. Design the incremental path from day one.

The Stack, For Reference

Framework: Next.js 14 App Router (Server Actions + Route Handlers)
Database: PostgreSQL via Supabase
Rollup updates: Supabase JS client with targeted update() calls inside the relevant API route handlers
Pattern: Event-driven incremental rollups at write time

Building something similar? Hit a different wall with PostgreSQL performance or Supabase at scale? Drop it in the comments — genuinely curious what patterns others are using for dashboard analytics on high-write systems.

How I Built a Custom WhatsApp Cloud Partner App to Slash Marketing Costs

Akash Pattnaik — Thu, 04 Jun 2026 07:49:23 +0000

Heya all 👋 I am the CTO at a dessert chain startup. We use WhatsApp marketing messages regularly to push content. In India, the cost per marketing message is 0.86 INR.

Till last month, we were using authkey.io. While reliable, the costs were starting to stack up as we scaled.

What is authkey.io?

Authkey.io is a cloud-based CPaaS (Communication Platform as a Service) that provides APIs for businesses to automate and manage customer communications across multiple channels. It allows developers and companies to integrate messaging and identity verification into their apps, websites, or software, often using a "pay-as-you-go" pricing model.

The Problem: Fixed Costs for Failed Deliveries

Since we are a startup, cost matters to us! I started noticing something—WhatsApp doesn’t actually charge for all messages, only for messages that are delivered. However, third-party providers often charge a flat rate (like 0.95 INR) per message sent, regardless of status. On our scale of 2,000 users with a 50% failure rate, we were paying significantly more than necessary.

I realized I could save 60-70% of our marketing costs by building our own system directly on the WhatsApp Cloud API.

Feature	Authkey.io (Third-Party)	Custom Cloud API (WhatsApp Cost)
Cost per Message	0.95 INR (per message sent)	0.86 INR (per message delivered)
Messages Sent	2,000	2,000
Messages Delivered	1,000	1,000
Total Cost Calculation	2,000 sent * 0.95 INR	1,000 delivered * 0.86 INR
Total Cost	1,900 INR 😭	860 INR 😃

The Architecture: Supabase, Next.js, and QStash

I built a customized solution using Supabase and a Next.js app deployed on Vercel. Leveraging serverless architecture was great, but I quickly hit the 5-minute execution limit on Vercel when broadcasting to thousands of users.

To solve this, I used QStash’s message queues. Instead of one long request, I send a single request to QStash to split numbers into batches of 20. QStash then triggers 100 separate requests to my Vercel deployment, each taking about 50-60 seconds. This ensured no messages were missed due to timeouts.

What is QStash?

QStash is a serverless messaging and scheduling solution designed specifically for HTTP and serverless environments. Created by Upstash, it functions as a middleman (message broker) that takes HTTP requests and forwards them to your target API endpoints. Instead of calling an endpoint directly, you send the request to QStash, which then handles the heavy lifting of background tasks and API integrations.

Optimizing Webhooks with Next.js 15+ `after()`

Using a Meta webhook route, I receive status updates and incoming messages. Initially, I used a "Fire-And-Forget" architecture, but Vercel containers would sometimes close before processing finished. I transitioned to the new after() API in Next.js 15, which allows work to continue after the response is sent. This magically slashed response times and improved reliability.

Connect with me 🙍

Mail - akashpattnaik.github@gamil.com
Github - iAkashPattnaik
Linkedin - iAkashPattnaik

I got tired of Googling Docker commands, so I built an interactive cheatsheet

Akash Pattnaik — Sun, 29 Mar 2026 15:17:29 +0000

Let me paint you a picture.

It's late. You're writing a Dockerfile. You're in the zone — the kind of focus where you're actually moving fast and everything is clicking. You type HEALTHCHECK and your fingers pause.

Is it --interval or --period? And what's the timeout default again? Is there a --start-period flag or did you make that up?

You open a new tab.

You type "dockerfile healthcheck options" into Google.

The first result is a Stack Overflow answer from 2017. The accepted answer is wrong. The second answer is right but references a flag that was renamed. You scroll past three more answers, open the official Docker docs, find the right section, get your answer, close five tabs, and try to remember where the hell you were.

Three minutes gone. Flow state: destroyed.

I've been doing this for years. And I finally got annoyed enough to do something about it.

What I built

Docker Hub is a free, open-source interactive cheatsheet for all 18 Dockerfile instructions. It lives in your browser, works offline, needs no login, and exists for one reason: so you never have to leave your editor to look up a Docker command again.

Here's the layout — three panels, all visible at once:

┌──────────────┬──────────────────────────┬──────────────┐
│  Cheatsheet  │   Interactive Dockerfile  │  Deep Dive   │
│   + search   │    (hover any keyword)    │  Reference   │
└──────────────┴──────────────────────────┴──────────────┘

Left panel — the cheatsheet

All 18 instructions, grouped by category, with a real-time search bar and category filter pills. Hover any instruction card and you get an instant tooltip summary. Click it and the right panel updates.

Center panel — the interesting part

This is what I actually wanted to exist. It's a realistic, multi-stage Node.js production Dockerfile rendered with token-level syntax highlighting. Every instruction keyword — FROM, RUN, COPY, HEALTHCHECK, all of them — is a hoverable, clickable span.

Hover HEALTHCHECK and you get a popover right there:

What it does
All its options (--interval, --timeout, --start-period, --retries)
A live code example
A link to the full reference

No new tab. No context switch.

Right panel — the full reference

Click any keyword and the right panel shows you everything:

Full description in readable prose
All syntax variants
A parameter table (type, required, default, and a BuildKit badge for flags that need it)
Multiple copy-ready code examples
A layer info strip (creates a layer? persists in image? runtime override flag?)
Related instructions you can jump to directly

The tech (keeping it boring on purpose)

This is a Next.js app with Tailwind CSS. That's basically it.

There's no backend. No database. No external API calls. The entire knowledge base is a single well-structured DATA.json file that gets imported at build time.

// lib/data.ts
import data from '../DATA.json'

export function getInstructionById(id: string): Instruction | undefined {
  return data.instructions.find(i => i.id === id)
}

export function searchInstructions(query: string): Instruction[] {
  const q = query.toLowerCase()
  return data.instructions.filter(i =>
    i.name.toLowerCase().includes(q) ||
    i.summary.toLowerCase().includes(q) ||
    i.tags.some(t => t.includes(q))
  )
}

The center panel's syntax highlighting is a custom tokenizer — not Prism, not Shiki, not any heavy library. Just a function that splits each Dockerfile line into typed tokens:

type TokenType = 'keyword' | 'flag' | 'string' | 'comment' | 'path' | 'plain'

interface Token {
  type: TokenType
  value: string
  instructionId?: string  // links keywords to DATA.json
}

function tokenizeLine(line: string): Token[] {
  if (line.trim().startsWith('#')) {
    return [{ type: 'comment', value: line }]
  }
  // first word = keyword if it matches a known instruction
  // --word = flag
  // /word or ./word = path
  // "word" = string
  // everything else = plain
}

Simple, fast, zero dependencies. Perfect for what we need.

The DATA.json schema — the real project

I want to talk about this because it's where most of the work actually went.

Each instruction in the JSON has a full semantic schema:

{
  "id": "healthcheck",
  "name": "HEALTHCHECK",
  "summary": "Defines a command to test container health",
  "description": "Full prose description...",
  "deprecated": false,
  "syntax": [
    "HEALTHCHECK [OPTIONS] CMD <command>",
    "HEALTHCHECK NONE"
  ],
  "layer": {
    "createsLayer": false,
    "persistsInImage": true,
    "overridableAtRuntime": true,
    "runtimeFlag": "--health-cmd, --health-interval"
  },
  "parameters": [
    {
      "name": "--interval",
      "type": "duration",
      "required": false,
      "default": "30s",
      "buildkitOnly": false,
      "description": "Time between health checks"
    }
  ],
  "examples": [
    {
      "id": "healthcheck-http",
      "title": "HTTP endpoint check",
      "description": "Check a health endpoint with curl",
      "code": "HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \\\n    CMD curl -f http://localhost:8080/health || exit 1"
    }
  ],
  "relatedInstructions": ["CMD", "ENTRYPOINT", "EXPOSE"],
  "tags": ["health", "monitoring", "check", "liveness"],
  "category": "runtime"
}

This schema is the reason the whole app is easy to contribute to. If you find a wrong example, a missing parameter, or a flag I forgot — you literally just edit the JSON and open a PR. You don't need to understand Next.js, React, or anything about the app. Just find the instruction, fix the data, ship it.

That was an intentional design decision. I wanted the knowledge base to be community-maintained without requiring any contributors to touch application code.

Things I learned building this

1. Token-level interactivity is a surprisingly underused pattern.

Most syntax highlighters treat code as display-only. Making each token interactive — hoverable, clickable, state-driving — forced me to think about the rendering differently. Instead of a <pre> tag, each line is an array of <span> elements with event handlers. Feels obvious in retrospect.

2. A JSON schema is a product decision, not a technical one.

I spent more time thinking about the shape of DATA.json than I did writing component code. Getting the schema right — deciding what fields an Example needs, how parameters should be typed, how to represent the CMD+ENTRYPOINT interaction matrix — was the hard part. The React components were almost mechanical after that.

3. Tooltip positioning is an unsolved problem and I respect Floating UI more now.

My first tooltip implementation overflowed the viewport constantly. The second one flickered. The third one used getBoundingClientRect() + a viewport-edge detection check and finally worked. I should've just used Floating UI from the start.

4. "No backend" is a feature, not a constraint.

Every time I was tempted to add a server route ("for search", "for analytics", "for saving custom Dockerfiles"), I asked myself: can this be done in the client with the static data? The answer was always yes. Keeping it fully static means it deploys anywhere, works offline, and has zero ongoing infrastructure cost.

What's next

A few things I want to add:

Custom Dockerfile input — paste your own Dockerfile and get it syntax-highlighted interactively with the same hover system
Docker Compose reference — same format, for docker-compose.yml keys
BuildKit toggle — hide/show BuildKit-only parameters to reduce noise for people on older Docker versions
Print export — a single-page PDF cheatsheet you can pin above your monitor

If any of those sound interesting to you, contributions are very welcome.

Try it / contribute

🐳 Live site: dockerhub
📦 GitHub: github.com/iakashpattnaik/docker_hub

The fastest way to contribute is to open DATA.json, find an instruction you know well, and improve its description, examples, or tags. That alone is enormously valuable.

If you find a bug, spot a wrong parameter, or think an instruction needs a better example — please open an issue or just send a PR directly. The bar is intentionally low.

And if this saves you even one "dockerfile COPY --chown syntax" Google search — that's the whole point.

Happy shipping. 🚀

For all vibe coders wanting to build apps - I strongly advise you read this once before you go on to chose a random framework!!

Akash Pattnaik — Tue, 13 Jan 2026 13:18:08 +0000

Akash Pattnaik

Jan 13

Why Flutter beats React Native ?

#flutter #beginners #programming #reactnative

2 min read

Why Flutter beats React Native ?

Akash Pattnaik — Tue, 13 Jan 2026 13:17:07 +0000

Performance 🚀

Flutter delivers superior performance because it compiles directly to native machine code. This eliminates the need for a JavaScript bridge, which React Native relies on. As a result, Flutter apps feel snappier and more responsive, particularly when handling complex UI and animations.

Consistent UI Across Platforms 🎨

Flutter uses a single codebase to create a consistent user experience on both Android and iOS. Since it draws its own widgets, the app looks the same across different platforms. React Native, on the other hand, uses native components, which can lead to slight differences in the UI across devices.

Hot Reload ⚡

Although both frameworks offer Hot Reload, Flutter’s implementation is faster and more reliable. Changes made to the app’s code can be seen almost instantly without needing a full app restart, speeding up development significantly.

Rich Widget Library 🛠️

Flutter provides an extensive collection of customizable widgets, offering more out-of-the-box functionality compared to React Native. With Flutter, developers can easily create visually appealing apps without depending heavily on third-party libraries.

Native Feel Without the Hassle 📱

Flutter's widgets replicate native UI elements closely, giving apps a native-like feel while allowing developers to customize the design easily. React Native sometimes requires additional work to bridge the gap between custom designs and native components.

Conclusion

In summary, Flutter stands out with its performance, consistency, rich UI tools, and a faster development process, making it the go-to choice for developers looking for a modern and efficient cross-platform solution.'

Connect with me 🙍

Mail - akashpattnaik.github@gamil.com
Github - iAkashPattnaik
Linkedin - iAkashPattnaik

10 Secret Tips That Make You Better at DSA

Akash Pattnaik — Mon, 12 Jan 2026 17:22:07 +0000

Introduction

Data Structures and Algorithms (DSA) often feel overwhelming at first. With so many concepts, patterns, and problem types, it’s easy to feel stuck or slow. But here’s the good news: becoming good at DSA is less about talent and more about strategy. The right habits, mindset, and techniques can dramatically speed up your progress. In this article, you’ll discover 10 secret tips that can make you significantly better at DSA, even if you’re starting from scratch.

Table of Contents 💻

Master the Basics Before Chasing Advanced Topics
Think in Patterns, Not Problems
Always Dry Run Your Code
Learn Time and Space Complexity Visually
Write Code on Paper (Yes, Really!)
Solve Fewer Problems, but Solve Them Deeply
Revisit Old Problems Regularly
Explain Your Solution Out Loud
Learn When Not to Use a Data Structure
Build Consistency, Not Motivation

1. Master the Basics Before Chasing Advanced Topics

Many learners rush into advanced topics like dynamic programming or graphs without fully understanding arrays, strings, and linked lists. This creates weak foundations. Spend time mastering basics like loops, recursion, and simple data structures. Strong fundamentals make complex topics feel easier and more logical.

2. Think in Patterns, Not Problems

Most DSA problems are variations of a few core patterns such as sliding window, two pointers, recursion, backtracking, or divide and conquer. Instead of memorizing solutions, train your brain to recognize these patterns. Once you spot the pattern, the solution becomes much clearer.

3. Always Dry Run Your Code

Before jumping into coding, dry run the logic step by step with a small example. This helps you catch edge cases, logical errors, and unnecessary steps early. Dry running also improves your problem-solving clarity and reduces debugging time.

4. Learn Time and Space Complexity Visually

Big-O notation can feel abstract. Instead of memorizing formulas, visualize how your algorithm grows with input size. Ask questions like: How many loops are running? or Is extra memory being used? This approach makes complexity analysis intuitive rather than confusing.

5. Write Code on Paper (Yes, Really!)

Writing code on paper forces you to slow down and think clearly. It improves logical flow and prepares you for interviews where you may not have an editor or auto-complete. This habit strengthens your confidence and precision.

6. Solve Fewer Problems, but Solve Them Deeply

Solving 100 problems poorly is less effective than solving 30 problems deeply. For every problem you solve:

Understand why the solution works
Explore alternative approaches
Analyze time and space complexity

Depth beats quantity in DSA learning.

7. Revisit Old Problems Regularly

Re-solving old problems after a few weeks is incredibly powerful. You’ll notice improved speed, better logic, and cleaner code. This reinforces long-term memory and helps patterns stick naturally.

8. Explain Your Solution Out Loud

If you can explain your solution clearly, you truly understand it. Try teaching the solution to a friend, or even to yourself. This technique exposes gaps in understanding and improves interview communication skills.

**9. Learn When Not to Use a Data Structure**

Many beginners overuse complex data structures when simpler ones work better. Always ask: Is this the simplest solution? Choosing the right (or minimal) data structure often leads to cleaner and faster code.

10. Build Consistency, Not Motivation

Motivation comes and goes, but consistency builds skill. Even 30 minutes of daily DSA practice is better than long, irregular sessions. Create a routine and stick to it. Progress will follow naturally.

Final Thoughts

Becoming better at DSA isn’t about shortcuts—it’s about smart learning. Apply these 10 secret tips consistently, and you’ll notice improved problem-solving speed, better confidence, and stronger fundamentals. Remember, every expert was once a beginner who didn’t give up.

End of ElephantSQL 😔

Akash Pattnaik — Wed, 03 Apr 2024 19:52:13 +0000

ElephantSQL started back in 2013 and it was one of the first services to offer postgreSQL at such low rates as a service.

I personally have been using it since last 4-5 years and my favorite part was the browser SQL executer.

Unfortunately 😟, just moments ago I received a mail saying that they are ending their services from January 27, 2025.

This marks a end to an era!

No doubt ElephantSQL was one of the best postgreSQL service providers out their for small projects.

I had build over 20 small projects using ElephantSQL. All of them had over 1K+ users. Their free plan was, in my personal opinion, the best postgreSQL service a beginner might ever get!

Comment if you have ever used ElephantSQL and what are you going to use from now one?!

File API

Akash Pattnaik — Thu, 21 Mar 2024 17:04:48 +0000

This is a submission for DEV Challenge v24.03.20, One Byte Explainer: Browser API or Feature.

`File` API

The File API allows web applications to interact with files on the user's device. It enables reading file content, accessing metadata, and handling file uploads, enhancing user experience with file management in web applications.

Example Code (Not a part of explanation)

// Reading file content using File API
const fileInput = document.getElementById('file-input');

fileInput.addEventListener('change', (event) => {
  // Get the selected file
  const file = event.target.files[0];

  // Create a FileReader object
  const reader = new FileReader();

  // Define what to do when file is loaded
  reader.onload = (event) => {
    // Retrieve the file content
    const fileContent = event.target.result;
    console.log('File content:', fileContent);
  };

  // Read the file as text
  reader.readAsText(file);
});

DOM API

Akash Pattnaik — Thu, 21 Mar 2024 17:03:46 +0000

This is a submission for DEV Challenge v24.03.20, One Byte Explainer: Browser API or Feature.

`DOM`

The Document Object Model (DOM) represents webpage structure in a tree-like format. It allows scripts to dynamically access, update, and modify webpage content and styles, enabling interactive web development.

Example Code (Not a part of explanation)

// Accessing and updating DOM elements
const heading = document.querySelector('h1'); // Selecting an element
heading.textContent = 'New Heading'; // Updating its text content
heading.style.color = 'blue'; // Changing its style
document.body.appendChild(heading); // Appending it to the document

fetch API

Akash Pattnaik — Thu, 21 Mar 2024 17:01:55 +0000

This is a submission for DEV Challenge v24.03.20, One Byte Explainer: Browser API or Feature.

`fetch` API

The Fetch API in browsers is for making HTTP requests. It's promise-based and cleaner than XMLHttpRequest. You can use fetch() with a URL and options to get data. Returns a promise with a Response object. Extract data with methods like .json().

Example Code (Not a part of explanation)

// Fetching data from a URL
fetch('https://api.example.com/data')
  .then(response => {
    // Check if response is successful
    if (!response.ok) {
      throw new Error('Network response was not ok');
    }
    // Extract JSON data from response
    return response.json();
  })
  .then(data => {
    // Work with the retrieved data
    console.log(data);
  })
  .catch(error => {
    // Handle any errors that occur during the fetch operation
    console.error('Fetch error:', error);
  });

The new BottomBar in Flutter

Akash Pattnaik — Sun, 17 Mar 2024 13:50:55 +0000

Hello fam 👋!

This tutorial shows the new BottomBar implementation in flutter. (It's official).

This is a new Material UI 3 implementation and is recommended to have only 3 childs (NavigationDestination).

For further lookup you can see here.

Here's a sample code that I used...

class AppHomePage extends StatefulWidget {
  const AppHomePage({super.key});

  @override
  State<AppHomePage> createState() => _AppHomePageState();
}

class _AppHomePageState extends State<AppHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: const SizedBox(),
      // Here
      bottomNavigationBar: NavigationBar(
          overlayColor: MaterialStateProperty.all(Colors.yellow),
          selectedIndex: _selectedIndex,
          onDestinationSelected: (int index) {
            setState(() {
              _selectedIndex = index;
            });
          },
          // indicatorColor: Colors.pink,
          destinations: const [
            NavigationDestination(
              icon: Icon(CupertinoIcons.home),
              selectedIcon: Icon(CupertinoIcons.house_fill),
              label: 'Home',
            ),
            NavigationDestination(
              icon: Icon(Icons.explore_outlined),
              selectedIcon: Icon(Icons.explore_rounded),
              label: 'Explore',
            ),
            NavigationDestination(
              icon: Icon(CupertinoIcons.bookmark),
              selectedIcon: Icon(CupertinoIcons.bookmark_solid),
              label: 'Saved',
            ),
            NavigationDestination(
              icon: Icon(CupertinoIcons.person),
              selectedIcon: Icon(CupertinoIcons.person_fill),
              label: 'Account',
            ),
          ],
       ),
    );
  }
}

The PlayStore Killer

Akash Pattnaik — Tue, 27 Feb 2024 18:29:08 +0000

It's 2024, and PlayStore is dominating the space in androids.

Towards the mid-end of 2023, PhonePe announced their own AppStore for India called Indus AppStore to compete against Playstore. Feb 21st is the date it's going to be released.

Features 🚀

This new AppStore comes with various new features and here are a few to list ->

Support for 13 India regional Languages
No fee for developers to list their apps.
AI integrated, you just need to enter your app details in english and they auto generate the same for the other 13 regional languages.
Ease of WebUI.

This is something I created as my first app to be listed on Indus. I invite you all too, to shift from playstore and get started with Indus.

DEV Community: Akash Pattnaik

From 5 Seconds to 50ms: How I Stopped Nuking My Database Every Time I Deleted an Order

My Dessert Shop Dashboard Was Choking on Its Own Data — Here's the Architecture That Fixed It

The Scene: A Dashboard Loading Like It's On Dial-Up

The Root Cause: Your Raw Table Is Not a Reporting Table

The Nuclear Rebuild: My First (Very Bad) Fix

The Epiphany: Pre-Aggregate at Write Time, Not Read Time

The Rollup Schema

The Architecture Shift

The Implementation: Incremental Reversals on Delete

One Important Caveat: Keep the Raw Table for Granular Queries

Key Takeaways for Dashboard Builders

The Stack, For Reference

How I Built a Custom WhatsApp Cloud Partner App to Slash Marketing Costs

What is authkey.io?

The Problem: Fixed Costs for Failed Deliveries

The Architecture: Supabase, Next.js, and QStash

What is QStash?

Optimizing Webhooks with Next.js 15+ after()

Connect with me 🙍

I got tired of Googling Docker commands, so I built an interactive cheatsheet

What I built

Left panel — the cheatsheet

Center panel — the interesting part

Right panel — the full reference

The tech (keeping it boring on purpose)

The DATA.json schema — the real project

Things I learned building this

What's next

Try it / contribute

For all vibe coders wanting to build apps - I strongly advise you read this once before you go on to chose a random framework!!

Why Flutter beats React Native ?

Why Flutter beats React Native ?

Table of Contents:

Performance 🚀

Consistent UI Across Platforms 🎨

Hot Reload ⚡

Rich Widget Library 🛠️

Native Feel Without the Hassle 📱

Conclusion

Connect with me 🙍

10 Secret Tips That Make You Better at DSA

Introduction

Table of Contents 💻

1. Master the Basics Before Chasing Advanced Topics

2. Think in Patterns, Not Problems

3. Always Dry Run Your Code

4. Learn Time and Space Complexity Visually

5. Write Code on Paper (Yes, Really!)

6. Solve Fewer Problems, but Solve Them Deeply

7. Revisit Old Problems Regularly

8. Explain Your Solution Out Loud

9. Learn When Not to Use a Data Structure

10. Build Consistency, Not Motivation

Final Thoughts

End of ElephantSQL 😔

File API

File API

Example Code (Not a part of explanation)

DOM API

DOM

Example Code (Not a part of explanation)

fetch API

fetch API

Example Code (Not a part of explanation)

The new BottomBar in Flutter

The PlayStore Killer

Features 🚀

Optimizing Webhooks with Next.js 15+ `after()`

**9. Learn When Not to Use a Data Structure**

`File` API

`DOM`

`fetch` API