-Compare stocks consistently across fundamentals, technicals and sentiment.
+A modular equity-analysis and portfolio engine for Indian markets, with a CLI, an API and a dashboard.
Why
Scattered fundamentals, technicals and sentiment are hard to compare. One pipeline makes the reasoning repeatable and testable.
How
Async ingestion with TTL caching and incremental refresh feeds a relational store. A registry of pluggable algorithms scores each stock, and a risk/return-aware optimizer builds the portfolio.
Result
13 registered algorithms, 1,300+ NSE stocks, backtesting and walk-forward calibration, and a React dashboard on top.
Why PostgreSQL only? Backtesting, run history and analysis snapshots are relational and need transactions and migrations. Running one database everywhere removes a whole class of local-versus-production differences.
Why async ingestion? The pipeline is I/O bound. Concurrent fetching with caching turns a slow serial crawl into something that can run daily.
Why a plugin registry for algorithms? Each algorithm is one file behind one interface and is registered by decorator. Adding or retiring one never touches the rest, and the docs are checked against the registry so they cannot drift.
Trade-offs
Operational simplicity (one database, one machine) over horizontal scale.
Measurability over cleverness: every algorithm must be scoreable against history.
A small, explicit public surface rather than exposing engine internals.
-Let people watch systems break instead of reading about them.
+A browser simulator: sketch a system, send traffic, watch it break, then fix it.
Why
System design is learned by seeing queues fill, pools run dry and retries pile up, not by reading about them.
How
A deterministic discrete-event engine in Go streams live state over WebSockets to a hand-drawn canvas UI in React.
Result
Guided challenges scored from one to three stars, request-trace waterfalls, chaos injection and shareable designs.
Under the hood
01Canvas UI02WebSocket session03Discrete-event engine04Chaos and traffic05Scenarios + scoring06REST API + sharing
Key decisions
Why Go for the engine? A tight event loop with predictable performance. A 30 s run of a 1,000 rps, 20-node design takes about 90 ms, so the simulation can run many times faster than real time.
Why deterministic? Same diagram and seed give the same result, which makes challenges fair, tests reliable and bugs reproducible.
Why run the simulation on the server? One authoritative engine, no duplicated logic in the browser, and the UI stays a thin editor and renderer.
Trade-offs
A request-flow and capacity model rather than a full distributed-systems emulator.
Stateful server sessions in exchange for live editing.
Anonymous sharing by capability link rather than accounts.