Hardik Tailor
This is a working document of technical projects, trade-offs, and accumulated context. Currently building distributed systems and exploring AI integration patterns. Most recent work involves real-time collaboration engines and platform architecture.
distributed-queue-system
Building a resilient task queue system for handling async operations at scale. The core challenge: maintaining consistency across multiple workers without sacrificing throughput. Initial phase focuses on PostgreSQL-backed queue with configurable retry logic.
Learning thread: What matters most is monitoring and observability, not algorithmic sophistication. Still exploring optimal batch windows and worker concurrency limits.
realtime-collaboration-engine
Multiple users editing shared documents required conflict resolution without locking mechanisms. Standard OT seemed overly complex for our use case.
Handles 50+ concurrent editors. Conflict rate under 0.1%. Main learning: broadcast throttling mattered more than resolution algorithm choice.
bitbloom
Platform for digital resource sharing and open-source collaboration. Developers create isolated resources; no unified place existed for monetizing alongside contributing to open-source.
Community-driven platforms live or die by UX. Infrastructure investment pays dividends. Still learning about user retention and sustainable growth models.
crux
AI-powered news platform exploring how contextual conversation transforms passive consumption into active exploration. Building real-time interface that makes news depth accessible.
Exploring optimal UX patterns for human-AI collaboration. Uncertain about long-term retention mechanics.
On database connection pooling
Been running into timeout issues at ~200 concurrent connections. Initially thought it was PostgreSQL max_connections limit, but turns out our pooler was misconfigured. Connection pool size ≠ database max connections. Pool should be smaller. Let the pool queue requests. Still not sure about optimal pool size. Currently testing with (num_cores * 2) + 1. Might be wrong.
Why I'm avoiding ORMs for this project
Decided to write raw SQL for the queue system. Yes, it's more verbose. But query plans are explicit, and optimization is direct. ORMs abstract exactly the things I need visibility into. This project prioritizes understanding over convenience.
AI interfaces and clarity
The best AI-powered interfaces are transparent about limitations. Users need to know what the model is seeing, what it's uncertain about. Not "Ask anything" but "Ask about [specific context]". Constraints create better experiences.
This document updates irregularly. Last significant revision: January 2026.