DEV Community: Alay Sharma

I shipped a hospital management system to production. Here's what actually broke.

Alay Sharma — Thu, 07 May 2026 15:43:32 +0000

Everyone ships demos. Localhost is kind — it has no users, no retries, no race conditions, no 3am failures. Production is where your assumptions get stress-tested by reality.

I built and deployed a full hospital management system: FastAPI backend, React web frontend, Flutter mobile app, Supabase PostgreSQL, Razorpay payments, Redis queues, and WhatsApp notifications via Selenium. Here's the post-mortem on what actually broke and how I fixed it.

1. Razorpay webhook idempotency — naive payment handling double-charges users

Razorpay retries failed webhooks. So does every serious payment processor. If your handler isn't idempotent, a network blip between their retry and your database write means you process the same event twice. The user gets charged once. Your DB thinks they paid twice. Chaos.

The fix isn't clever code — it's a database constraint.

I added a deduplication_key column on the payment_webhooks table with a unique index. Every webhook payload carries a Razorpay event ID. On arrival: insert it, process it, or fail silently if the key already exists. No conditionals, no if already_processed. The database enforces it.

CREATE UNIQUE INDEX idx_payment_webhooks_dedup 
ON payment_webhooks(deduplication_key);

Payment logic should be a pure function of an event ID. If you've seen it before, return 200 and do nothing. That's it. Any other approach is a liability waiting to surface at the worst possible time.

2. WhatsApp automation via Selenium — why the official API isn't always the answer

The Meta Business API requires a verified business, a WABA account, approved message templates, and per-message fees. For a hospital running 40 bookings a day in India, the economics don't work. So I automated WhatsApp Web via Selenium.

Here's what breaks in production: QR code expiry, DOM changes after WhatsApp Web updates, headless Chrome memory leaks, and silent rate limiting from Meta's side if you push volume.

I fixed it with three things:

Session persistence — Selenium reuses a Chrome user profile that stays logged in. No re-scanning QR codes on every restart.
Dead-man's switch — a watchdog process that kills and restarts the driver if a successful send hasn't been confirmed in 10 minutes.
Audit trail — every outbound message is written to a whatsapp_logs table with status (sent, failed, retrying). Hospitals are accountable institutions. You need the record.

The Selenium approach is fragile by nature. You accept that fragility and build resilience around it — you don't pretend it's stable infrastructure.

3. Redis async task queue — why synchronous notification dispatch blocks everything

First version of the booking flow: confirmation saved → Selenium sends WhatsApp → API returns response. Selenium takes 3–8 seconds to open a conversation thread and send a message. Your API is blocking that entire time. Under any load, requests pile up, timeouts compound, and a booking endpoint that should return in 200ms becomes a 9-second operation.

Decoupling is the only fix.

The booking endpoint now does one thing: write a job to a Redis queue, then return 200. A separate background worker consumes the queue, handles Selenium, retries on failure, updates whatsapp_logs. The API doesn't care about notification state.

# Endpoint — fast, non-blocking
redis_client.lpush("notification_queue", json.dumps(job_payload))
return {"status": "confirmed"}

# Worker — slow, isolated, retryable
while True:
    job = redis_client.brpop("notification_queue", timeout=5)
    dispatch_whatsapp(job)

Response time went from 5–9 seconds to under 300ms. The booking logic was always fast. I was just carrying unnecessary weight in the hot path.

4. Multi-role JWT + Supabase RLS — the mistake most tutorials make

The common tutorial pattern: encode the user's role in the JWT payload, check it in your route handler, gate the endpoint. Looks fine. It's not.

A stale token carries stale permissions. A doctor whose account was suspended can still read patient data until their token expires. In a healthcare system, that's not acceptable.

I encode only a user_id in the JWT. On every request, FastAPI fetches the current role from the database — live, not cached in the token. Supabase Row Level Security then enforces data access at the storage layer, independent of the application layer.

# Dependency — resolves role fresh on every request
async def get_current_user(token: str = Depends(oauth2_scheme)):
    user_id = decode_jwt(token)
    return await db.fetch_one("SELECT * FROM users WHERE id = $1", user_id)

Three independent enforcement layers: JWT for identity, DB lookup for current role, RLS for data access. Any one of them catches what the others miss. That's defense in depth — not just a phrase, an actual architectural decision.

5. Flutter + React + FastAPI — keeping two frontends honest against one database

The failure mode looks subtle at first. Mobile app caches an appointment as confirmed. Web dashboard still shows it as pending. A doctor sees one state. The patient sees another. Support calls happen. Trust erodes.

Two frontends reading the same data isn't inherently a distributed systems problem — until you let each client own its own state. Then it is.

Supabase is the single source of truth. Not an API response, not local state in either client. Both Flutter and React read from the same PostgreSQL database through the same FastAPI layer. Neither client writes directly to Supabase outside of realtime subscriptions for live updates.

The rule I enforced: every mutation goes through the API. No client-side optimistic writes that don't have a confirmed server echo. No divergent data-fetching logic between platforms. One schema, one API contract, two consumers.

When you have two frontends, consistency isn't a feature you add later. It's a constraint you build into your data layer from the start.

The honest lesson

Production doesn't care about your architecture diagrams.

It cares whether your payment handler is idempotent at 2am when Razorpay fires a retry. It cares whether your notification worker recovers without a manual restart. It cares whether a role change propagates before the next API call hits your route guard.

Demos prove that something can work. Production proves that it does — repeatedly, under pressure, without you watching. That's a completely different engineering problem, and most systems only find out the difference after they've already failed.

Beyond "Vibe Coding": Architecting a Zero-Copy Hybrid C++/Python HFT System

Alay Sharma — Sun, 29 Mar 2026 10:45:01 +0000

Everyone is drunk on “vibe coding”—prompt a model, get thousands of lines, feel like you shipped something real. That illusion collapses the moment you enter a domain where latency is a P&L variable. In HFT, a single unpredictable pause isn’t a bug—it’s lost edge.

I didn’t “use AI to build a trading system.” I used it as a compiler for syntax while taking full ownership of architecture, memory, and failure modes. That distinction is everything.

The Real Problem: Latency vs. Intelligence

You’re forced into a false trade-off:

C++ → deterministic, nanosecond execution, zero tolerance for abstraction overhead
Python → flexible, ML-native, but plagued by GIL, GC pauses, and jitter

If you pick one, you lose.

So don’t pick.

The Only Viable Model: Separation of Concerns at the Process Level

Not microservices. Not APIs. Not containers.

Hard separation of responsibilities at the memory boundary.

1. The Hot Path (C++ — Nervous System)

Owns the NIC
Ingests raw UDP/WebSocket ticks
Normalizes into a strict binary schema
Writes to memory with deterministic timing
No branching logic, no ML, no allocation-heavy operations

This process is sacred. You don’t “optimize” it later. You design it to be untouchable from day one.

2. The Smart Path (Python — Brain)

Reads normalized data
Computes features (EWMA, efficiency ratios, etc.)
Runs model inference (PyTorch)
Emits execution signals

It’s allowed to be complex. It’s not allowed to touch latency-critical infrastructure.

The Critical Insight: IPC Is the Hidden Bottleneck

Most people destroy their system here.

Sockets, Redis, gRPC—these are all latency leaks disguised as architecture:

Serialization cost
Kernel traversal
Context switching
Memory duplication

You don’t fix this with faster code. You remove the layer entirely.

The Actual Edge: Shared Memory + Zero-Copy Semantics

POSIX shared memory (mmap) creates a single physical memory region
C++ writes directly into a lock-free ring buffer
Python maps the same region—no transfer, no duplication

Now combine that with Flatbuffers:

Data is read in-place
No deserialization
No object creation

Result:

Zero IPC overhead
Zero-copy reads
Minimal GC pressure

You didn’t “speed things up.” You eliminated an entire class of latency.

Where Most Systems Blow Up: Unbounded Intelligence

Fast systems fail faster.

An ML model making decisions at microsecond scale without constraints is a liability, not an advantage.

So you enforce physics over intelligence.

The Shadow Book (Local Reality Approximation)

Markets have latency. Your system shouldn’t pretend they don’t.

Maintain an internal, optimistic state of positions
Assume fills before confirmation
Prevent duplicate or conflicting orders

Without this, your strategy degenerates into self-induced noise.

The Watchdog (Control Plane, Not Feature)

Your smartest component is also your most fragile.

External process monitors heartbeat (e.g., ZeroMQ)
Missed signal = immediate termination
No recovery logic inside the failing system

You don’t debug a live trading engine. You kill it before it damages capital.

What “Vibe Coders” Miss Entirely

They focus on:

Writing code faster
Generating features
Plugging models

They ignore:

Memory layout
Cache locality
Allocation patterns
Failure isolation
Deterministic execution guarantees

That’s why their systems look impressive—and fail silently under load.

Final Reality

AI can:

Generate syntax
Suggest patterns
Accelerate iteration

AI cannot:

Design memory-safe, latency-deterministic systems
Anticipate race conditions across processes
Enforce risk boundaries under real-world constraints

If you don’t understand the machine at the level of memory, scheduling, and physics, you’re not building an HFT system.

You’re just simulating one—until the market proves otherwise.

Why AI-Powered IPS Systems Fail and How I Reduced False Positives by 96% Without Blocking Traffic

Alay Sharma — Sun, 15 Feb 2026 18:07:19 +0000

Intrusion Prevention Systems (IPS) don’t usually fail because the models are weak.
They fail because detection and enforcement are tightly coupled.

Most modern “AI-IPS” designs still follow the same flawed logic:

Detect → Decide → Block

This works in controlled benchmarks.
It collapses in production.

In this post, I’ll explain:

why false positives explode in AI-IPS systems,
why better models alone don’t solve the problem,
and how a staged, decoupled architecture with honeypot feedback reduced false positives by 96% in my prototype — without blocking benign traffic.

The Core Problem: IPS Is Treated as a Classification Task

Most AI-IPS pipelines are framed as binary classification:

Traffic → Features → Model → {Malicious | Benign}

The implicit assumption:

High confidence = safe to enforce
Low confidence = model problem

That assumption is wrong.

Why?

Because network traffic is adversarial, ambiguous, and non-stationary.

Even a 98% accurate classifier can:

block legitimate but rare traffic,
mislabel new application behaviors,
fail catastrophically during distribution shifts.

In production, false positives are more damaging than false negatives:

They break services
Trigger alert fatigue
Force operators to disable enforcement entirely

That’s why many IPS deployments quietly downgrade into IDS-only mode.

The Real Issue: Detection ≠ Decision

The mistake is architectural, not statistical.

Most systems bind:

detection certainty directly to enforcement action

In reality, “uncertain” traffic is not “benign” or “malicious”.
It’s unverified.

Treating uncertainty as a classification failure guarantees noise.

My Approach: Decoupled, Staged Validation

Instead of asking:

“Is this packet malicious?”

I reframed the problem as:

“How much confidence do we have right now to enforce action?”

High-level architecture

Traffic
  ↓
Fast ML Detection Layer
  ↓
Confidence-based Routing
  ├── High confidence → Immediate enforcement
  ├── Low confidence → Pass-through
  └── Ambiguous → Dynamic honeypot / sandbox
                     ↓
              Behavioral verification
                     ↓
               Feedback to detector

The key shift:

Detection produces a signal
Decision is deferred unless confidence is sufficient

Why Honeypots Matter (and Not as Traps)

In this system, honeypots are not passive decoys.

They are:

verification instruments
used only for ambiguous traffic
dynamically selected based on protocol and behavior

Instead of blocking suspicious flows:

I let them interact in a controlled environment
observe command patterns, persistence, retries, payload changes
and then retroactively update trust

This turns uncertainty into signal.

Results (Prototype Evaluation)

Using the UNSW-NB15 dataset as a baseline:

Baseline false positive rate: 12.8%
After staged validation: 0.48%
Net reduction: ~96.2%

Latency impact:

ML inference: ~0.003–0.007 ms amortized per flow under batched execution (batch size dynamically determined by ingress buffering and scheduler constraints (≈143,000 flows/sec))
Honeypot routing: applied only to the ambiguous traffic subset, leaving high-confidence benign and malicious flows on the fast path
Overall impact: no blanket performance degradation on backbone traffic, as enforcement and verification are decoupled from primary detection

Crucially:

No legitimate traffic was blocked purely on model output
Enforcement only happened after behavioral confirmation

Why This Works Better Than “Better Models”

I tried:

deeper ensembles
tighter thresholds
feature engineering

All of them helped marginally.

None solved the core issue.

The improvement came from system design, not model tuning.

Key principles:

Separate signal generation from action
Treat uncertainty as a first-class state
Use interaction, not prediction, to resolve ambiguity

Implications for AI Security Systems

This pattern generalizes beyond IPS:

Fraud detection
Abuse prevention
Account takeover detection
Even EO/GeoAI risk verification

Anywhere false positives are expensive:

Decoupling detection from enforcement is mandatory.

What I’d Do Next

If this were production-bound:

Replace static honeypots with adaptive service emulations
Add long-term trust scoring
Integrate cross-session behavioral memory
Move toward agent-based verification instead of rule-bound traps

Closing Thought

AI doesn’t fail security systems.
Coupling does.

If your system can’t say “I’m not sure yet”,
it will eventually say “block everything” — or nothing at all.

By

Alay Sharma

The Domestic Turn of Information Warfare: When Democracies Target Their Own Minds

Alay Sharma — Mon, 10 Nov 2025 18:01:59 +0000

By Alay Sharma

The 20th century taught nations to fear bombs and borders.
The 21st will teach them to fear their own narratives.

The Paradox
For decades, democracies framed information warfare as an external threat a battle waged by adversaries seeking to distort elections, destabilize institutions, or polarize societies. But in the past five years, a quieter transformation has begun.
The very tools once built to defend truth from foreign interference are now being repurposed internally not by rogue actors, but by states, corporations, and political machines operating within the democratic framework itself.

The paradox is stark:
To defend citizens from manipulation, democracies have started to master manipulation.

From Propaganda to Persuasion Architecture
Information control no longer looks like wartime censorship. It looks like algorithmic persuasion the ability to engineer emotional response through feeds, recommendation systems, and data-driven behavioral nudges.
The battlefield has shifted from the public square to the private scroll.
The weapons are no longer slogans, but signal amplification models trained on human attention itself.
Where propaganda once shouted, persuasion architectures whisper reshaping opinion invisibly, efficiently, and, most dangerously, legally.

The Dual Use Dilemma
Every information weapon has a dual-use problem.
The same AI models that detect disinformation can be tuned to suppress dissent.
The same behavioral analytics that build resilience against influence can be used to micro-target emotional vulnerabilities in the name of engagement or “national harmony.”
It is not foreign powers that pose the gravest long-term cognitive risk to democracies it’s the normalization of domestic influence infrastructure.
When democracies adopt the tools of control once feared in authoritarian regimes, they no longer defend minds they occupy them.

The Cognitive Erosion of Freedom
Freedom of speech is often misunderstood as the freedom to speak.
In the digital age, its true essence is the freedom to think unshaped.
When every exposure, every frame, and every search result is optimized for persuasion, the population becomes a substrate for behavioral engineering.
At that point, the distinction between defense and domestic cognitive warfare collapses.
This is how democracies erode not through coups or censorship, but through algorithmic paternalism: the quiet conviction that citizens must be guided for their own good.

A Call for Cognitive Ethics
The real defense now lies not in counter-propaganda, but in cognitive ethics frameworks governance models that separate defensive information operations from domestic influence systems.
Just as we drew bright lines around biological weapons and nuclear deterrence, we must establish norms around cognitive sovereignty:

Prohibit the use of psychological manipulation tools on domestic populations.

Enforce transparency for algorithmic narrative shaping.

Protect the cognitive commons the shared mental environment—as a democratic institution.
Without these norms, democracies will win the information war against their enemies, only to lose it against themselves.

The Closing Question
If truth becomes programmable, and persuasion becomes policy
who will defend the human mind from its own defenders?

InformationWarfare #CognitiveSovereignty #AIethics #NationalSecurity #DigitalGovernance #Democracy #PsychologicalOperations #MediaStrategy #CyberPolicy

The next great battleground isn’t oil, chips, or data. It’s your mind.

Alay Sharma — Wed, 10 Sep 2025 17:46:35 +0000

UCLA recently revealed a groundbreaking innovation: a non-invasive brain-computer interface that enhances real-world task performance by 4 times. This advancement, achieved through a wearable EEG device paired with AI, eliminates the need for surgery or implants.

Simultaneously, the BRICS group, now comprising 10 members and 10 partners, is transcending its economic origins to become a formidable alternative governance model challenging Western systems.

A significant concern arises with the potential vulnerability of one's thoughts if accessible through a headset, opening avenues for theft, manipulation, and even weaponization. The battleground has shifted from phones and data to the realm of cognition itself.

As nations grapple with the implications, the erosion of sovereignty looms large when control over shaping minds and securing signals is compromised. The rivalry between BRICS and the West extends beyond traditional realms to defining standards for mental autonomy.

The proposed solution and call to action revolve around the necessity for Cognitive Constitutions akin to trade treaties of the past. Just as nuclear deterrence and financial security shaped previous eras, safeguarding neural data is poised to define the future landscape.

IntelPatch: An Autonomous AI-Powered CVE Intelligence System

Alay Sharma — Tue, 15 Jul 2025 21:45:02 +0000

Can an AI system understand vulnerabilities, evaluate risk, and suggest mitigations — all without human help?

That’s what I set out to build with IntelPatch.

🔥 What is IntelPatch?

IntelPatch is a fully autonomous, multi-agent CVE intelligence system that parses real-world CVEs, simulates red-team reasoning, and generates human-grade vulnerability insights and patch recommendations.

It's built using CamelAI’s OWL framework, and can run completely offline via Ollama, making it ideal for secure environments.

🧠 What It Does

🧾 Scrapes and parses CVEs in real-time
🧠 Uses multiple reasoning agents to analyze severity and exploitability
🛠️ Suggests practical mitigations based on past exploits, configs, and patch databases
🔍 Scores risk based on CVSS, historical PoCs, and impact vectors
📦 All running fully locally with no internet dependency

⚙️ Tech Stack

Languages: Python (agents, parsing), Shell (automation)
LLM Integration: Ollama (offline LLM serving)
Multi-Agent System: CamelAI OWL framework
Data Sources: MITRE CVE feeds, ExploitDB, vendor advisories
Design Pattern: Autonomous role-based agents with task delegation

🧩 How It Works

CVE Ingestion Agent → pulls recent CVEs
Parsing Agent → extracts vulnerability fields
Exploit Risk Agent → analyzes threat level & known exploits
Mitigation Agent → suggests fixes and patches
Summarization Agent → generates human-readable report

Each agent operates independently, communicates via a shared memory channel, and reasons using OWL's role-based planner.

💡 Why I Built This

Manual CVE triage is:

🔁 Repetitive
🧍 Prone to error
🐢 Slow during active threat windows

IntelPatch acts as a virtual analyst, automating threat evaluation so defenders can respond faster and smarter.

🔗 Links

📦 GitHub: https://github.com/mrvenom17/intel-patch
📜 Full README: Includes architecture + agent breakdown
🌐 Portfolio: https://alay.vercel.app

📈 What’s Next?

[ ] Add CVE → PoC → Patch mapping using ExploitDB
[ ] Integrate a local vector DB for semantic similarity
[ ] Add scoring dashboard with charts + risk heatmaps
[ ] Add PoC testing in sandboxed environment

- [ ] Submit to CamelAI + OWL agent gallery

IntelPatch isn’t a script — it’s a thinking system.

Built solo. Fully open source. Always improving.

If you work in threat intel, cyber defense, or autonomous systems — I’d love your feedback or collab. Let’s build machines that defend like humans, but faster.

→ Drop a ⭐ on GitHub

→ Comment or share if this resonates

— Alay Sharma

SecureShare: A Zero-Knowledge, Blockchain-Powered Platform for Secure File Sharing

Alay Sharma — Tue, 15 Jul 2025 21:32:47 +0000

Imagine sharing sensitive files — medical records, legal docs, or private datasets — with someone halfway across the world…

Without trusting Google, Dropbox, or anyone in between.

🔐 That’s what I built: SecureShare — a blockchain-powered, zero-knowledge file sharing platform with:

📦 On-chain access control (no centralized permissions)
🔐 Client-side encryption (data stays yours)
📜 Immutable audit logs (for compliance + accountability)
🔄 Real-time notifications + access tracking
🔓 Role-based access control + enterprise SSO
⚡ Layer-2 support for gas savings (Polygon, Arbitrum)

🚀 Tech Stack

Frontend: React 18 + TypeScript + TailwindCSS + Zustand
Blockchain: Solidity + Sepolia Testnet + Wagmi + Viem
Backend: Node.js + Express + SQLite + Prisma
Security: CryptoJS encryption, JWT auth, Helmet, Rate Limiting
UI/UX: Framer Motion + drag-n-drop upload zone + WebSocket updates

🛠 How It Works

You connect your wallet (MetaMask or any EVM-compatible)
Upload a file → it gets client-side encrypted
File hash is stored on-chain + mapped to your wallet
You grant access to other Ethereum addresses (RBAC-style)
All access grants/revokes are logged immutably on the blockchain
Your dashboard shows every access event, confirmed on-chain

Every file, every access, every log — fully transparent, fully trustless.

🌐 Why This Matters

We’re entering a world where data sovereignty and privacy are non-negotiable.

🔎 Centralized systems can be hacked, censored, or tampered with
🧠 Blockchain lets us build trustless systems with verifiable permissions
🛡️ Zero-knowledge and encryption ensure privacy without compromise
⚙️ Enterprises need compliance (GDPR, HIPAA, SOX) — SecureShare bakes that in

Whether it’s used by healthcare firms, legal teams, journalists, or decentralized orgs — SecureShare ensures you control who sees your data, and when.

🔗 Project Links

💻 GitHub Repo: SecureShare
🌐 Live Demo: https://secureshareforanonimity.netlify.app/

👨‍💻 What’s Next?

IPFS + Filecoin integration
zk-SNARK-based permission verification
White-label SaaS for enterprises
SDK + REST API for dev integrations

Built it solo, from scratch — code, contracts, infra, UI, security.

Would love feedback, collaborations, or feature requests.

Let’s build sovereign systems — where you own your data, not rent it.

Drop a star ⭐ or DM anytime.

— Alay Sharma

Blockchain #CyberSecurity #Web3 #ZeroKnowledge #Privacy #SaaS #React #OpenSource #Solidity #Ethereum