Hi, I'm Nirajan
Software Engineer & Web Developer
Co-founder at Lingo Tech Solutions, building scalable web platforms and digital solutions for growing businesses. I build Next.js SEO optimized websites for global startups — brands, websites & apps that rank on Google and AI search and generate leads.
Currently pursuing BSc. (Hons) in Software Engineering, I combine academic knowledge with practical experience to deliver high-quality web solutions for international clients.
Work Experience
Co-founder & CTO
Software Development & IT ConsultingKey Achievements:
- Co-founded a software development and IT consulting company delivering web, mobile, and SEO solutions.
- Led architecture and full-stack development using modern technologies (React, Next.js, Node.js).
- Built and deployed production websites and business systems for clients.
- Managed product planning, performance optimization, and scalable deployment.
- Contributed to UI/UX, SEO strategy, and technical decision-making.
Key Achievements:
- Led development of multiple web applications using React and Node.js
- Implemented CI/CD pipelines reducing deployment time by 50%
- Mentored junior developers and conducted code reviews
- Collaborated with cross-functional teams to deliver high-quality solutions
Education & Qualifications
BSc. (Hons) in Software Engineering
In ProgressPursuing with honors. Focused on software engineering and AI/ML.
Visit Institution Website
School Leaving Certificate (SLC)
CompletedCompleted 10+2 (Science Stream) under NEB, Nepal, with a GPA of 3.71.
Visit Institution Website
Futsmandu
Full-Stack SaaS · Production
A production multi-tenant futsal booking platform running 12 Docker containers on a single VPS — foue distinct API servers (Admin, Player, Owner and Chat Service) each with their own async Worker, backed by Postgres advisory locks for concurrency-safe slot reservations and dual eSewa payment flows for native app-to-app checkout.
Sole architect, backend engineer, and DevOps. Designed the booking engine, payment integration, real-time chat microservice, and the entire container orchestration from scratch.
Tech Stack
12
Docker Containers
5
Booking Defence Layers
2
eSewa Payment Flows
Infrastructure & DevOps
12 Docker containers on a single VPS — every service isolated, independently deployable, with zero single point of failure at the application layer.
- 3-stage multi-stage Dockerfile (deps → builder → runner) — no TypeScript compiler or dev tools in the final image
- Nginx is the only container with host ports 80/443; all internal traffic is plain HTTP on Docker's virtual network
- Cloudflare in front: VPS IP hidden, DDoS absorbed, SSL at edge — Nginx trusts Cloudflare IP ranges for X-Forwarded-For
- Fail2Ban monitors Nginx logs and bans IPs after repeated 4xx/5xx or brute-force patterns on auth endpoints
- CI/CD via GHCR — migrate container runs as a one-shot before any API starts, then exits cleanly
Traffic Flow — Internet to App
Cloudflare
DDoS Protection · CDN · SSL at Edge
Nginx
Reverse Proxy · TLS Termination · Rate Limiting
Fail2Ban · UFW
IP Banning · Host Firewall · Port 22/80/443 only
12 Docker Containers
API · Worker · PostgreSQL · Redis
Booking Engine
A 5-layer double-booking prevention system that runs cheapest-first — from pure in-memory validation all the way down to Postgres advisory locks and range-overlap queries.
- pg_try_advisory_xact_lock(court:date:time) — serializes concurrent identical requests, auto-released on transaction end, zero deadlock risk
- Slots held for 3 minutes with PENDING_PAYMENT status; BullMQ job auto-expires stale holds
- booking_meta JSONB written once at holdSlot(), read at confirmPayment() — immutable single source of truth
- Range overlap query: start_time < endTime AND end_time > startTime catches any partial overlap on HELD/PENDING/CONFIRMED rows
5-Layer Defence — Cheapest First
Date Guards
UTC-normalized past/future validation — zero DB hits
User Eligibility
Reliability score · ban_until · suspension check
Active Hold Guard
Player cannot hold 2+ slots in parallel — SELECT check
Postgres Advisory Lock
pg_try_advisory_xact_lock(court:date:time) — auto-released, zero deadlock
Range Overlap Query
start_time < endTime AND end_time > startTime — catches partial overlaps
eSewa Payment — Dual Flow
Two production payment integrations sharing the same security model: the server is always the price authority, HMAC verified before any DB write.
- Web v2 (ePay): HMAC-SHA256 over total_amount + transaction_uuid + product_code; base64 decode + HMAC verify on redirect
- Intent API: native deep-link to eSewa app, MPIN/biometric auth, futsmandu:// scheme returns control to Flutter
- Atomic claim via updateMany WHERE status IN [INITIATED, PENDING] prevents concurrent verify race — 409 Conflict on contention
- Idempotency keys on all payment upserts guard against duplicate webhook replays
Dual Payment Flow
eSewa Web v2
Browser / WebView flow
eSewa Intent API
Native deep-link · no WebView · MPIN auth
Real-Time Chat
Dedicated NestJS microservice with Socket.IO, Redis Pub/Sub for horizontal scaling, and a dual-secret JWT guard re-validated on every message event.
- Two dedicated Redis connections per instance — shared pub client + isolated sub client (Redis protocol mandates this separation)
- @socket.io/redis-adapter broadcasts room events across all server instances for true horizontal scale
- Presence system: 30s Redis TTL + 10s app heartbeat to keep TTL alive; redis.del() on disconnect — no TTL wait
- Inbox Room pattern: every user is auto-joined at connect so new chat initiations reach users before they open the chat
- Firebase FCM push via BullMQ — HTTP returns immediately, FCM delivery is fully async in the worker process
Chat Architecture
Redis Pub/Sub
Horizontal scaling across server instances via @socket.io/redis-adapter
Dual JWT Auth
PLAYER_JWT_SECRET + OWNER_JWT_SECRET — re-validated on every message event
Presence System
Redis TTL 30s + 10s app heartbeat. redis.del() on disconnect — no TTL wait
Firebase FCM
Async push via BullMQ — HTTP returns immediately, FCM delivered in worker
Connection Lifecycle
Async Queue Architecture
BullMQ decouples every async operation from the HTTP path — each domain has its own worker process with an independent retry strategy and independent scaling.
- Booking expiry, push notifications, email delivery, analytics aggregation, payment reconciliation — all queue-driven
- Slow admin export jobs cannot delay critical player booking confirmations — domain isolation enforces this
- Workers are independently scalable: player-worker ×3 without touching admin or owner workers
- SchedulerService registers BullMQ repeatable jobs on startup for scheduled recurring tasks
Domain-Isolated Workers — BullMQ / Redis
player-worker
owner-worker
admin-worker
chat-worker
↑ Slow admin export jobs cannot delay critical player booking confirmations. Workers are independently scalable.
Key Engineering Takeaway
Every design decision here — Postgres advisory locks over app-level mutexes, immutable JSONB booking_meta, domain-isolated workers, atomic concurrent-verify claims — was driven by correctness under concurrency, not convenience. This is what production looks like.
Support & FAQ
HAVE QUESTIONS?
FIND ANSWERS.
Everything you need to know about starting your digital journey in Nepal. If your question isn't here, feel free to reach out.
As a Software Engineer Freelancer in Nepal, I offer comprehensive digital solutions including professional website development, mobile app development, UI/UX design, and SEO services. My team and I focus on building custom, performance-oriented applications that drive business growth.
Still have questions?
Can't find what you're looking for? Let's talk directly.