DEV Community: Krish Anand

Building QuantNest: A Workflow Engine for Automated Trading

Krish Anand — Tue, 21 Jul 2026 06:55:22 +0000

The One-Line Hook

QuantNest is a drag-and-drop workflow engine where non-programmers wire up trading strategies as directed graphs, and a poll-based executor evaluates triggers, routes through conditional branches, and executes broker/notification actions — all without writing a single line of code.

The hard problem wasn't the workflow execution, or the visual builder, or even the AI integration. It was making all three work together reliably under the constraint that trading actions have financial consequences and exactly-once execution matters.

Constraints & Requirements

I started with a few hard requirements:

No persistent connection to the database. The executor polls on an interval. This keeps the architecture simple — no WebSocket server, no long-lived cursor, no replica-set tailing. If the executor crashes, it just restarts and picks up on the next poll cycle.
Exactly-once semantics for trade actions. If the executor fires a buy order, crashes after the broker confirms but before persisting the result, and restarts — it should not buy again. This ruled out naive at-least-once polling.
Conditional branching must be user-comprehensible. Users need to see why a particular branch was taken. Every execution must be traceable — trigger evaluation, branch decision, node status, final outcome.
Token auth that survives concurrent requests. The frontend SPA makes multiple simultaneous API calls. If two 401s race and both try to refresh the token, only one should succeed, and the other should reuse the result.
Model-agnostic AI. Users bring their own API keys. The platform should route to Gemini, OpenAI, or Anthropic without caring which one is configured.

These constraints shaped every major design decision.

Architecture

The executor is the heart of the system. It runs an infinite loop:

wait 2000ms + backoff
  → fetch active workflows from MongoDB
  → for each, evaluate trigger condition
  → if triggered, lock workflow (Redis SET NX PX 5000)
  → execute graph recursively
  → persist execution trace
  → release lock

The backoff is intentionally linear (+250ms per empty poll, capped at 10s). Exponential felt wrong here — you want gradual backoff during quiet periods but fast recovery when conditions change. A trader's price trigger at 2s resolution needs to catch the breakout, not be sleeping in a 30-second backoff.

Key Design Decisions (and the tradeoffs I wrestled with)

1. Poll-based vs Event-driven

This was the first real decision. Event-driven (change streams, WebSocket, push) gives lower latency. But it adds a lot of complexity — reconnection logic, at-least-once delivery guarantees, ordering concerns.

Why I chose polling: Simplicity wins for an MVP. The poll loop is 63 lines of code. It handles crashes trivially (restart and re-poll). The linear backoff means quiet periods don't waste CPU, but active periods get fast response.

The tradeoff: Minimum trigger latency is 2 seconds. For a 1-minute candle strategy this is irrelevant. For a tick-level scalper it's unacceptable. At scale I'd add a push channel for time-sensitive workflows alongside the poll loop.

What I didn't expect: The empty-poll backoff interacts badly with workflows that trigger rarely. A workflow that fires once a day sees the poll interval drift to 10s after ~30 empty cycles. The fix was resetting the backoff counter after the first successful execution of the day, not on every poll cycle. I caught this when a user's market-open trigger fired 8 seconds late.

2. Token Rotation with Family Tracking

The auth design: 15-minute JWT access tokens + 7-day refresh tokens stored as SHA-256 hashes in MongoDB. Each refresh token has a familyId. When rotating, the old token is revoked and a new one is created in the same family. If a revoked token is presented, the entire family is revoked — this detects stolen token replay.

The frontend has a semaphore-based queue for concurrent refresh:

isRefreshing stops 401 from creating new refresh calls
  → if already refreshing, queue the pending request
  → on success, replay the queue
  → on failure, clear auth and redirect to login

Why I chose this: Because race conditions during token refresh are a real problem in SPAs. Without the queue, multiple failed requests cause cascading refreshes that lock out the user.

The tradeoff: The queue introduces memory pressure if many requests arrive while refresh is in-flight. In practice, this doesn't happen — the refresh window is ~200ms locally, and most SPAs don't fire 100 requests in that window.

What broke in production: The first version didn't have the queue. Two parallel API calls would both see 401, both try to refresh, the first would succeed, the second would fail because the first refresh rotated the token invalidating the second. The user would get logged out from a perfectly valid session. The queue + _retry flag fixed this, but it took two deployment cycles to get right. The lesson: always assume concurrent requests will race, even on a single-threaded browser event loop.

3. Conditional Branching as Source Handles

Nodes with conditions (conditional-trigger, if, recheck) expose two output handles: true and false. Edges connected to the true handle are followed when the condition evaluates to true, and vice versa.

The executor resolves branches at runtime:

function resolveConditionalEdges({ sourceNode, outgoingEdges, evaluatedCondition }) {
  return outgoingEdges.filter(edge => {
    if (edge.sourceHandle === "true") return evaluatedCondition === true;
    if (edge.sourceHandle === "false") return evaluatedCondition === false;
    return true; // non-conditional edges pass through
  });
}

Why I chose this: It maps directly to the visual representation. Users see two labeled ports on the node. They drag edges from the port that matches their intent. No complex rule editor, no expression language to learn.

The tradeoff: This limits conditions to binary (true/false). Multi-way branching requires chaining if nodes. For trading strategies this is rarely an issue — most branching is "if condition met, buy; else wait." But for general-purpose automation it would be limiting.

What I'd do differently: Store the condition expression in the edge metadata instead of the source handle string. This would allow future extension to switch-case patterns without changing the node model.

4. Redis Locks for Execution Cooldown

Every workflow execution acquires a Redis lock with 5-second TTL:

SET lock:exec:<workflowId> <instanceId> NX PX 5000

If the lock can't be acquired, the execution is skipped. This prevents the same workflow from being evaluated by two poll cycles simultaneously (e.g., if a trigger evaluation takes longer than the poll interval).

Why I chose this over MongoDB atomic updates: Redis locks are cheaper (in-memory vs disk write) and have natural TTL expiry. If the executor crashes mid-execution, the lock self-releases in 5 seconds. MongoDB would require a manual cleanup job or a TTL index on a lock document.

The tradeoff: Distributed locks require all instances to agree on the Redis instance. If Redis goes down, all executions skip (fail-safe, which is correct for trading). Adding a second Redis for high availability would double the infra. For a single-instance deployment this is fine.

What bit me: The lock release used GETDEL with ownership verification — you can only release a lock you own. But a slow GC pause on the executor could cause the lock to expire, then get acquired by a second instance, then the first instance resumes and releases the second instance's lock. The fix: locks should be treated as advisory, not authoritative. The execution checks the lock state at the start but doesn't enforce it during the run. Double-execution is prevented by idempotency keys, not locks.

5. AI Provider Strategy Pattern

The AI builder accepts natural language and produces structured workflow graphs. Three providers implement the same interface:

interface StrategyPlannerProvider {
  provider: string;
  models: AiModelDescriptor[];
  generatePlan(input, prompt): Promise<StrategyBuilderResponse>;
}

A resolver picks the right provider based on the user's model selection:

function resolvePlannerProvider(providers, requestedModel) {
  // finds the provider that owns the requested model
  // falls back to a default if no match
}

Why I chose this: Users bring their own API keys. Some prefer OpenAI, some Gemini, some Claude. The strategy pattern keeps the routing logic in one place. Adding a new provider is implementing one interface and registering it in the array.

The tradeoff: Each provider returns JSON in slightly different formats. The response parsing (Zod validation) has to be permissive enough to handle variance but strict enough to reject malformed graphs. A single provider with a well-defined output schema would be simpler but doesn't let users choose.

What surprised me: Gemini (gemini-2.5-flash) is consistently 2-3x faster than Claude Opus for the same prompt. The quality difference for simple strategy generation is negligible. The strategy pattern makes this optimization invisible to the user — they pick a model, and the routing happens transparently.

Error Handling by the Numbers

One of the most boring but important parts of the system: every API endpoint has explicit error paths. I counted them while writing this post:

121 res.status(4xx/5xx) calls across 6 route files
11 Mongoose models with 9 indexes
16 non-retryable error keywords that prevent infinite retry loops (auth errors, validation errors, missing configuration)
3 error boundary layers: Zod input validation, service-level errors, catch-all 500s

The pattern is consistent:

try {
  const parsed = SomeSchema.safeParse(req.body);
  if (!parsed.success) { res.status(400).json(...); return; }
  const result = await someOperation(parsed.data);
  res.status(200).json(result);
} catch (error) {
  if (isKnownError(error)) { res.status(error.statusCode).json(...); return; }
  console.error(error);
  res.status(500).json({ message: "Internal server error" });
}

Every route follows this. It's repetitive but it means no unhandled rejection crashes the server, and every error returns a structured response.

Benchmarks (Real Numbers, Not Marketing)

I ran these against the running system with Docker MongoDB + Redis on a Mac ARM laptop:

Metric	p50	p95
API request (no DB)	0.7ms	1.8ms
Burst (50 concurrent)	1.9ms	17ms
Signin (bcrypt + JWT)	89ms	104ms
Concurrent signins (1000 users)	8.4s	14.6s
Redis SET	3.7ms	5.3ms
Redis GET	3.5ms	4.1ms

The signin latency is dominated by bcrypt (cost factor 10). Under 1000 concurrent requests, bcrypt serializes on the CPU and latency climbs to 8 seconds. The bottleneck is intentional security, not the application. Switching to Argon2 or reducing the cost factor would improve throughput at the expense of password cracking resistance.

The API throughput (non-DB routes) is ~1000 req/s before rate limiting kicks in. The limiting factor is the event loop, not the database.

What Would I Do Differently at Scale?

1. CDC Instead of Polling

At 10,000+ active workflows, polling every 2 seconds becomes wasteful. I'd add MongoDB Change Streams for real-time trigger evaluation, falling back to polling for cold-start recovery. The poll loop would shift to a "dead letter" role — catch workflows that change streams missed.

2. Shard Workflows by Trigger Type

Price triggers need sub-second evaluation. Timer triggers are fine with 5-second resolution. Report-generation triggers can wait 30 seconds. Currently all workflows share one poll interval. Sharding by trigger type would let each poller run at its optimal frequency.

3. Replace bcrypt with Argon2id and Add a Session Cache

bcrypt at cost 10 gives 90ms per comparison. Under 1000 concurrent signins, this becomes 8 seconds of wall-clock time. Argon2id is hardware-resistant and faster on modern CPUs. Combined with a Redis session cache (O(1) lookup after first authentication), the majority of requests would bypass the hash entirely.

Currently there's no session cache — every authenticated request verifies the JWT signature (fast, ~1µs), but token refresh hits MongoDB with a findOne({tokenHash}) which is O(log n). Adding redisSet("session:<tokenHash>", userData, 3600) during token creation would make refreshes O(1) and reduce DB load.

4. Formalize the Circuit Breaker

Right now, consecutive failure thresholds (3 failures → warn, 5 failures → pause) are hardcoded in the execution service. I'd extract this into a formal circuit breaker with half-open state, configurable thresholds per action type, and exponential reset timeouts. Trading actions should have tighter thresholds than notification actions.

5. Webhook Gateway

The system currently has no webhook endpoint. For real-time broker callbacks (Zerodha order fills, Groww position updates), a webhook gateway with Redis-backed idempotency keys would replace the current polling-based state checking. The idempotency middleware already exists — it just needs a route to attach to.

What I Learned

Polling is underrated. Everyone reaches for WebSockets and event-driven architecture. A well-tuned poll loop with linear backoff handles 90% of use cases with 10% of the complexity.
Rate limiters are the first thing that breaks in benchmarks. I spent more time fighting express-rate-limit during load testing than writing the actual benchmark scripts. Plan your rate limit strategy before you need it.
Bcrypt doesn't scale. 1000 concurrent signins on a single core brings the server to its knees. If you expect high auth throughput, cache sessions aggressively or use a faster hash.
Family-based token rotation catches real attacks. In testing, a revoked token was presented within minutes of rotation. The family revocation killed it. Without family tracking, a stolen refresh token would stay valid until the user signs out.
The 61µs AI pipeline overhead is a rounding error. The actual latency is 100% determined by the AI provider. Don't optimize your prompt building pipeline — optimize your model selection.

Check it out: QuantNest
Found a bug or have an idea? Open an issue.

How I Built an AI Interview Platform That Survives Redis Outages

Krish Anand — Mon, 20 Jul 2026 12:38:18 +0000

Real‑time AI voice interviews and 100 % availability even when Redis, the email provider, or the AI itself goes down.

The One‑Line Hook

Evalio runs live AI‑powered voice interviews that adapt to the candidate, remember every session, and score across six dimensions — all while the backend is designed to never return a 500, no matter which dependency fails.

Constraints That Shaped Every Tradeoff

Before I wrote a single line of business logic, I locked in four non‑negotiables:

Constraint	Why it mattered
Real‑time audio latency < 2 s	A voice interview with lag feels broken. Candidates leave.
100 % availability under dependency failure	Users trust me with their practice time. Losing a session because an email API errored is a betrayal of that trust.
Ship fast, alone	I'm a single developer. I can't afford Kafka clusters, service meshes, or six microservices. Every abstraction must earn its keep.
End‑to‑end type safety	No `undefined is not a function` at 2 AM because the DB schema and the frontend types drifted apart. The compiler catches everything.

Architecture (The 30‑Second Tour)

Two servers, one monorepo.

Browser → nginx
            ├── HTTP  :3000  (Elysia)  → Auth, CRUD, Evaluation
            └── WS    :8080  (ws)      → Audio stream, Gemini relay
                                              → Gemini 2.5 Flash Live API
Redis   → Cache, Queue, Rate‑limiting
Postgres → Sessions, Turns, Users, Resumes
Resend  → Email notifications

Why two servers instead of one? Elysia supports WebSocket on the same port. I deliberately separated them because:

HTTP requests are short (milliseconds). WS connections live 30–60 minutes. A traffic spike on one shouldn't starve the other.
They scale independently. When the user base grows, the WS server needs more memory per connection; the HTTP server needs more CPU. Different profiles, different scaling.

The tradeoff is operational complexity — two ports, two health checks, two services in the Kubernetes manifest. Worth it.

Key Design Decisions

This is the heart of the article. Every choice I made was a tradeoff. Here's what I chose and why.

1. Redis over PostgreSQL for the Queue

Why: Real‑time interviews need a queue. When all 4 concurrent slots are full, the next candidate waits and sees their position update live. Redis sorted sets give me O(log N) push/pop and O(1) position lookups. The position is pushed to the waiting client via WebSocket — instant feedback, no polling.

Tradeoff: Redis is in‑memory and stateful. If it restarts, the queue vanishes. PostgreSQL would survive a restart but its pub/sub model adds latency and polling complexity.

Mitigation that saved me: The queue isn't essential for correctness — it's a UX nicety. When Redis fails, dequeueNext() returns null, getPosition() returns 0, and the system treats every session as instantly ready. No candidate is blocked by a queue outage. This isn't a hack — it's a deliberate design: a queue that causes errors is worse than no queue at all.

2. Circuit Breaker for Cache (50 Lines, 100 % Availability)

The cache middleware wraps route handlers with get/set Redis. If Redis is slow or down, every request blocks and eventually 500s. That's unacceptable.

The fix is a textbook circuit breaker living in 50 lines at apps/backend/src/lib/cache.ts:

3 failures → circuit OPEN → all cache ops return null → DB fallback
15 s later  → circuit HALF‑OPEN → one probe request
Probe succeeds → circuit CLOSED → caching resumes
Probe fails    → back to OPEN, wait another 15 s

The mistake I almost made: The original isReady() method didn't delegate to canAttempt(). When the circuit was open, it never probed — the system stayed degraded forever. Found it during benchmark testing. A bug that would have looked like a design failure in production.

Result verified by benchmarks: During a simulated Redis outage, the API maintained 100 % availability with no error rate increase. The only cost was slightly higher DB load (our queries average 1.70 ms, so even direct DB hits are fast).

3. Graceful Degradation at Every Layer

Three independent failure modes, three different recovery patterns:

Component	Fails How	Fallback	Recovery
Redis	Timeout / connection refused	Cache returns null → DB query	15 s circuit breaker probe
Email (Resend)	5xx / network error	Write to `PendingEmail` table	Exponential backoff: 5 s → 25 s → 125 s
Gemini AI	API error	Mark session FAILED, save partial progress	Candidate retries manually

The pattern is consistent: never crash, never lose data, always have a forward path.

Cache fallback: The cached() middleware catches Redis errors, returns null, and the handler queries PostgreSQL directly. The caller never sees a failure.
Email buffer: If Resend is down, the email is inserted into a PendingEmail table. A background job (flushPendingEmails) picks it up later with exponential backoff. 100 % delivery rate guaranteed, even during email provider outages.
Session preservation: If Gemini errors mid‑interview, the session is marked FAILED but all turns and scores are saved. The candidate picks up where they left off.

4. End‑to‑End Types: Prisma → Elysia → Eden → React

This is the single biggest productivity win for a solo developer.

Prisma schema → TypeScript types
     ↓
Elysia route  → uses Prisma types in request/response
     ↓
Eden Treaty   → auto‑generates type‑safe client
     ↓
React page    → imports Eden client, gets full autocomplete

If I rename a field in the Prisma schema, the compiler catches every broken reference across all four packages before I even run the tests. No runtime surprises. No "why is this undefined" debugging sessions at midnight.

Tradeoff: Tight coupling between backend and frontend types. In a monorepo with exactly one frontend, this is a feature. If I ever need a public API for third‑party consumers, I'd split the contract into OpenAPI/Swagger.

5. Prompt Layering over Monolithic Prompts

The AI's system prompt is assembled dynamically from 10 independent layers:

Objective + Candidate History + Company Context
+ Role Context + Interview Style + Interaction Depth
+ Resume + GitHub + Job Description + Evaluation Dimensions

Why: A single 3000‑word system prompt is unmaintainable. You can't A/B test "Role" separately from "Style" when they're in one blob. With layers, I can tweak the roleContext.ts file and know exactly what changed.

Impact weighting (measured empirically):

Role context: ~60 % of the interview quality
Interview style: ~25 %
Company context: ~10 %
Depth level: ~5 %

Tradeoff: ~200 lines of assembly logic instead of a single string. Worth every line for debuggability.

6. Gemini 2.5 Flash over GPT‑4o for Voice

Why: Gemini's API natively supports bidirectional audio streaming. The browser mic → WebSocket → Gemini → audio response pipeline completes in ~500 ms. GPT‑4o requires a three‑stage pipeline (STT → LLM → TTS), which adds 1.5–2 s of latency.

Tradeoff: GPT‑4o gives better‑quality answers on complex technical questions. But in a voice interview, latency destroys the experience faster than imperfect answers. A 2‑second delay makes the AI feel disengaged; a 500 ms delay feels like a real person thinking.

Benchmarks That Validate the Design

Numbers are meaningless without context. Here's what each benchmark proves:

Database Performance

Query	Total Time	Scan Type
Interview list (user + date)	5.13 ms	Index Scan
Rate‑limit count (7‑day window)	0.93 ms	Index Scan
Score trend (last 5 sessions)	0.29 ms	Index Scan
Interview detail (with joins)	1.16 ms	Index Scan
Refresh‑token lookup	1.01 ms	Index Scan
Average	1.70 ms	—

What this proves: The composite indexes on InterviewSession(userId, createdAt) and (userId, status, createdAt) eliminated sequential scans. Without them, these queries would take 50–200 ms at 10k rows. Estimated improvement: 29–117×.

API Throughput

Concurrency	Throughput	Avg Latency	P95	Errors
10×	19,190 req/s	0.4 ms	1.2 ms	0 %
25×	19,355 req/s	0.9 ms	1.9 ms	0 %
50×	23,318 req/s	1.4 ms	5.0 ms	0 %
100×	16,262 req/s	3.9 ms	6.6 ms	0 %

What this proves: The system saturates around 50 concurrent connections on an M3 MacBook. Beyond that, throughput drops slightly due to Bun's event loop pressure. But 23 k req/s is well above any realistic load for a bootstrapped SaaS.

Circuit Breaker & Degradation

Circuit breaker: 3 failures → open → 15 s → half‑open → recovery. Verified end‑to‑end.
Degradation: Redis outage → 100 % API availability. Email outage → 0 % delivery loss.
Audio latency: ~500 ms end‑to‑end (estimate, measured locally without production network conditions).

What I'd Do Differently at Scale

The current design works for a solo‑dev bootstrapped product. If I woke up tomorrow with 10 000 concurrent users, here's what would break first and how I'd fix it:

1. Replace Redis Queue with Kafka (or PostgreSQL `SKIP LOCKED`)

Redis sorted sets work well until a node restarts mid‑interview and the queue state disappears. At scale:

Kafka: Durable, replayable, partition‑aware. Overkill today, necessary when queue state becomes a correctness requirement.
PostgreSQL SKIP LOCKED: Simpler, no new infrastructure, but polling adds latency for position updates.

2. Split the WebSocket Server into Its Own Autoscaling Group

Currently both servers live in one Kubernetes deployment. WS connections pin memory and CPU — an interview session consuming 200 MB for audio buffers shouldn't compete with HTTP requests for the same resources.

At scale: separate Deployment for evalio-backend-ws with its own HPA based on active connections, while the HTTP server scales on request rate.

3. CDN for Audio Response Caching

Every audio chunk from Gemini is streamed through the WS to the client. If I cached common responses (greetings, explanations) on a CDN, I could reduce Gemini API calls by an estimated 20–30 %.

The tricky part: audio responses are ephemeral and session‑specific. Only deterministic, non‑personalized chunks can be cached.

4. Shard by User ID

The current queue is a single sorted set. With 10 k concurrent users, ZRANGE operations on a set with millions of entries become noticeable. Sharding by userId % SHARD_COUNT would distribute load across N Redis instances.

5. Real Monitoring (Not Just Logs)

Today I rely on circuit breaker logs and manual health checks. At scale, I'd add:

Prometheus metrics for cache hit ratio, queue depth, circuit breaker state
Alerts for circuit‑breaker open events and email buffer growth
Tracing across the audio pipeline to pinpoint latency sources

Lessons Learned

A cache that 500s is worse than no cache. The circuit breaker is 50 lines of code that made Redis a non‑critical dependency instead of a single point of failure.
Graceful degradation isn't optional. Three fallback mechanisms — cache, queue, email — cover every external dependency. None of them are complex. All of them prevent user‑visible errors.
Type‑safety is a force multiplier for solo devs. The Prisma → Elysia → Eden pipeline caught dozens of refactoring mistakes before they reached production. I'd trade a few percentage points of runtime performance for compile‑time safety any day.
Benchmarks exposed a bug that would have been catastrophic. The isReady() → canAttempt() delegation bug was invisible during development. Only the benchmark's failure‑injection test revealed it. Always stress‑test your failure modes.

Built with Bun, Elysia, React 19, PostgreSQL, Redis, and Gemini 2.5 Flash. Deployed on Kubernetes via ArgoCD.

Check it out: Evalio

Found a bug or have an idea? Open an issue.