Escrowly is a production-grade escrow platform built to handle complex financial transactions between parties. The system was engineered for reliability, correctness, and scale. In financial software, a single lost event or duplicate transaction can break trust irreparably.
\nI worked on the core backend infrastructure, contributing across the payment pipeline, event architecture, and service design.
\nFinancial systems can't tolerate data loss. The challenge was ensuring that every transaction event was delivered exactly once in practice, even if services crashed mid-flight, retried on failure, or experienced transient network issues.
\nA naive approach: publish an event to Kafka after writing to the database. It fails silently. If the service crashes between the DB write and the Kafka publish, the event is gone. No retry. No alert. Just silent inconsistency.
\nI implemented the transactional outbox pattern to eliminate this gap:
\nWrite + queue atomically. Events are stored in an outbox table as part of the same database transaction as the business operation. If the transaction rolls back, the event is never queued. If it commits, the event is guaranteed to exist.
\nReliable publisher with retries. A separate publisher process polls the outbox table and pushes events to Kafka with retries and exponential backoff. This decouples the publish from the original transaction, so Kafka failures never affect the source of truth.
\nIdempotent consumers. On the consumer side, events are deduplicated using transaction IDs. Even if Kafka delivers the same event multiple times, the processing logic produces the same result: no double charges, no duplicate state changes.
\nEscrowly is built on a distributed microservices architecture with dedicated services for each business domain. The platform covers identity and access, transaction lifecycle management, financial accounting, regulatory compliance, real-time notifications, analytics, and client-facing APIs. Each service owns its own data and event contracts, meaning teams can evolve independently without cross-service migration risk.
\nServices communicate asynchronously via Kafka where eventual consistency is acceptable, and synchronously via REST where immediate responses are required.
\nWhy the outbox pattern over direct Kafka publishing?
\nDirect publishing creates a two-phase commit problem. You cannot atomically write to a database and publish to Kafka. The outbox pattern sidesteps this entirely by making the database the single source of truth. Kafka becomes the delivery mechanism, not the record of what happened.
\nWhy idempotent consumers over exactly-once delivery?
\nKafka's exactly-once semantics add significant operational complexity and latency. Idempotent consumers are simpler to implement, easier to test, and degrade gracefully. If a duplicate arrives, it is ignored cleanly. This approach treats retries as a feature, not a problem.
\nWhy PostgreSQL per service?
\nDomain isolation. Each service owns its schema so teams can evolve independently. Financial ledgering in particular needs strong ACID guarantees that PostgreSQL provides reliably.
\nIn distributed systems, reliability comes more from system design than from individual components behaving perfectly.
\nThe outbox pattern is a good example: instead of hoping every component stays up at exactly the right moment, the design assumes failures will happen and builds durability into the data flow itself. The system is correct by construction, not by luck.
"}},{"node":{"id":"26fb2597-33f8-5d34-939a-a250f582339f","frontmatter":{"title":"Coinperps - Real-Time Analytics Platform","category":"web","duration":"Ongoing","team":"Team","status":"completed","performance":"99%","users":"Live","uptime":"99.9%","rating":"5.0","tech":["Node.js","Express","MongoDB","Redis","WebSockets","Puppeteer","Node-Cron","Winston"],"github":null,"external":"https://coinperps.com","date":"2025-02-01"},"html":"Coinperps is a real-time analytics platform built for traders who need consolidated market data across exchanges in one place. Think funding rates, liquidations, open interest, ETF flows, Fear and Greed Index, market vitals, and a live news feed, all served through a fast, reliable API.
\nI built the core data pipeline and backend infrastructure: ingestion, processing, caching, and serving, end to end.
\nMarket Data never stop. Data that is 60 seconds old can already be stale for a funding rate during peak volatility, but the same 60-second rule applied to static ETF data would waste server resources and add unnecessary load. The challenge was building a system that could handle high-frequency ingestion across multiple data types while serving each one at exactly the right freshness level.
\nGetting this wrong in either direction has consequences. Too aggressive: server overload, rate limiting from upstream sources, degraded response times. Too conservative: stale data that traders cannot trust.
\nI designed a tiered caching strategy where each data type gets its own TTL based on how often it actually changes:
\nThe result: the API stays fast under load because hot paths hit in-memory cache, and upstream data sources are only called as often as they need to be. Redis handles shared caching across instances with distributed locking via Redlock to prevent thundering herd on cache misses.
\nFor live exchange data, I integrated a WebSocket layer that maintains persistent connections and pushes updates to clients as they arrive. This eliminated the need for clients to poll and significantly reduced server load for high-frequency data endpoints.
\nBeyond market data, Coinperps needed a live news feed. I built a parallel news ingestion system that scrapes major market news outlets on a schedule, extracts structured article data (title, author, reading time, source), deduplicates across runs, and serves results through a clean API.
\nThe scraper layer runs all sources concurrently with rate-limiting via a priority queue, respects robots.txt policies, and handles source-specific markup differences gracefully. If one source fails, the rest continue unaffected.
\nOn top of that, I built a Twitter/X monitoring system that tracks high-signal market accounts and ingests their latest posts every few minutes, with deduplication using MongoDB's $addToSet so the same tweet never appears twice regardless of how many polling cycles catch it.
A cron scheduler handles all periodic data ingestion: funding rate snapshots, open interest updates, liquidation data, ETF list refreshes, long/short ratio aggregations, and more. Jobs are isolated so a failure in one does not cascade. Logging via Winston gives full visibility into job outcomes for debugging and monitoring.
\nWhy tiered caching over a single TTL?
\nFinancial data has wildly different freshness requirements depending on its type. A one-size-fits-all TTL would either serve stale funding rates or hammer upstream APIs with unnecessary requests. Tiering is the only approach that scales correctly.
\nWhy parallel scraping with a queue?
\nRunning scrapers sequentially would make the news feed as slow as the slowest source. Running them all at full concurrency risks overwhelming upstream sites and triggering rate limits. A bounded concurrency queue gives the best of both: fast parallel execution within safe limits.
\nWhy MongoDB's $addToSet for tweet deduplication?
\nIt makes deduplication atomic at the database level. There is no separate read-then-write cycle that could allow duplicates under concurrent writes. The database enforces uniqueness as part of the insert itself.
\nIn data-heavy systems, the right caching strategy is the product, not an afterthought. How you decide what to cache, for how long, and how to invalidate it determines whether your API feels live or feels stale. Getting that architecture right early means the rest of the system can scale around it.
"}},{"node":{"id":"d44f5afc-f64f-5175-b8ed-bb1d6fb28cb1","frontmatter":{"title":"Flyverr - Secure Marketplace MVP","category":"web","duration":"4 weeks","team":"Team","status":"completed","performance":"99%","users":"12K+","uptime":"99.9%","rating":"4.9","tech":["Node.js","Next.js","PostgreSQL","Supabase","Stripe","Row-Level Security"],"github":null,"external":"https://flyverr-frontend.vercel.app/","date":"2024-03-15"},"html":"I had 4 weeks to deliver a digital marketplace MVP that would support creators and resellers of limited digital products. The challenge was not just to launch quickly, but to design a system that could handle thousands of transactions, keep payments fully compliant, and protect user data. At the same time, the business needed a foundation that was flexible enough to scale and adapt after launch.
\nWe launched on time with a modular backend, secure data policies, and seamless payment flows. The platform gave the company a market-ready product that could onboard users, validate the business model, and generate early revenue.
\nThis was not a simple prototype. The business wanted Flyverr to stand out from day one:
\nMy role was to translate these goals into a clear engineering plan and execution that delivered both technical reliability and business value.
\nI designed and built the marketplace end-to-end with a focus on both speed and long-term scale:
\nAlternatives considered
\nDatabase-level security\nWe enforced granular database-level security policies, which added early complexity but significantly reduced long-term risks of data leakage or privilege escalation.
\nReliable payment events\nWe standardized payment event handling to ensure reliable, debuggable flows, which restored full confidence in transaction consistency.
\nTriggers for critical state changes\nCritical state changes were enforced at the database layer, ensuring consistency and integrity across different services regardless of where the updates originated.
\nThis project was about more than building features. It was about giving the business a platform that could earn trust, handle growth, and evolve without costly rewrites. By focusing on scalability, security, and simplicity, we delivered a marketplace MVP that balanced immediate deadlines with long-term vision.
"}},{"node":{"id":"47fce642-2b3c-50c7-b376-bf2086d7fbc8","frontmatter":{"title":"Trader Agent - AI-Powered Trading Assistant","category":"ai","duration":"3 months","team":"Solo Developer","status":"completed","performance":"96%","users":"1.2K+","uptime":"99.9%","rating":"4.8","tech":["Claude.ai","Node.js","Express","MongoDB","React.js","WebSocket","JWT","bcrypt"],"github":"https://github.com/talhariaz324/trader-agent","external":"https://gleeful-valkyrie-cb2dda.netlify.app/","date":"2024-02-20"},"html":"Built an intelligent trading assistant powered by Claude.ai that provides real-time market analysis, automated trading suggestions, and comprehensive portfolio management for cryptocurrency traders.
\nCryptocurrency trading requires:
\nThis project taught me:
\nDeveloped a cutting-edge real-time multiplayer gaming platform that supports thousands of concurrent users with dual-currency system (in-game coins and USDT) for seamless purchases and trading.
\nThe gaming industry needed a scalable solution that could handle:
\nThis project taught me the importance of:
\nDeveloped a comprehensive healthcare management platform that streamlines patient care, appointment scheduling, and medical record management for healthcare providers and patients.
\nHealthcare providers needed a solution for:
\nThis project taught me:
\n