# Mohd. Hussain Ansari Software Development Engineer 2 · Back-end Engineering - **Name:** Mohd. Hussain Ansari - **Current role:** Software Development Engineer 2 at INK IN CAPS - **Discipline:** Back-end Engineering - **Experience:** 4+ years - **Looking for:** SDE 3, Senior Backend Engineer, Backend Engineer - **Availability:** 30-day notice period - **Location / work mode:** Mumbai, Maharashtra, India; Mumbai (on-site / hybrid) or remote - **Core stack:** Node.js, NestJS, TypeScript, MongoDB, PostgreSQL, Redis, AWS - **Email:** mohd.hussainansari19@gmail.com - **LinkedIn:** https://linkedin.com/in/mohd-hussain-ansari - **GitHub:** https://github.com/Mohd-Hussain-Ansari - **Résumé (HTML):** https://hussainansari.dev/resume - **Résumé (PDF):** https://hussainansari.dev/hussain-ansari-resume.pdf ## Summary Back-end engineer with over four years designing and running production systems in Node.js, NestJS and TypeScript. My work sits where correctness matters most: payment and subscription lifecycles, wallet and ledger mechanics, and real-time infrastructure that has to stay consistent across many servers at once. - I design real-time WebSocket infrastructure on Socket.IO and Redis Pub/Sub, fanned out across multiple servers, currently carrying 3,000+ concurrent connections for messaging and notifications. - I work on payment and transaction processing — gateway workflows moving roughly $462K USD a month across about 7,700 transactions for 30K+ users, alongside subscription lifecycle, idempotency, retry, wallet and ledger functionality. - I take ownership of performance and migrations: 800+ sellers moved with zero data loss, schema and indexing reworked across 2.7 million records, and a 25% improvement in query latency. - I have led a 10-member cross-functional team of back-end and QA engineers, running requirement gathering, feature discussion, and product demos with founders and clients across London, Dubai and Canada. ## Experience ### Software Development Engineer 2 — INK IN CAPS (Mumbai) Dec 2025 — Present Back-end engineering on a creator subscription platform: real-time messaging infrastructure, the subscription and wallet money paths, and the async job layer behind them. - Designing real-time WebSocket infrastructure on Socket.IO and Redis Pub/Sub across multiple servers for live messaging and notifications. - Managing the end-to-end subscription lifecycle — activation, renewal, expiry, invoicing, retries and failure recovery — with idempotency mechanisms that prevent duplicate charges. - Building wallet and ledger functionality for credit, debit and balance tracking with atomic, consistent transactions. - Running Redis-backed BullMQ queues so renewals, notifications and invoicing happen outside the request path. - Developing signature-validated webhooks and push notification pipelines on AWS EC2, ALB, Route 53, Lambda, SES and S3. - Redesigned a slow home-feed endpoint, cutting load time by ~75% and data transfer by up to 90% under typical usage. ### Product Developer (Back-end) — AppOctet Technologies (Mumbai) May 2022 — Oct 2025 Progressed from mobile app developer to product developer — shipping React Native apps before taking ownership of back-end architecture, third-party integrations, code review, mentoring, and production releases across several products. - Led back-end development across product engagements, owning architecture, reusable APIs, integrations, reviews, mentoring, production systems and releases. - Drove back-end reliability by identifying recurring failure scenarios and strengthening error handling across production applications. - Improved deployment through Docker-based automation — deploys following code push and a green test run, with less manual intervention. - Led the technical migration of 800+ sellers with zero data loss, and optimised schema and indexing across ~2.7 million records for a 25% query latency improvement. - Recognised as Star Performer in both 2024 and 2025. ## Skills - **Languages:** TypeScript, JavaScript (ES6+), Java - **Runtime & Frameworks:** Node.js, NestJS, Express.js - **Data:** MongoDB, MySQL, PostgreSQL, Redis, Mongoose, TypeORM, Prisma - **Async & Real-Time:** BullMQ, Redis Pub/Sub, Socket.IO, WebSockets, Agenda, Delayed jobs, Retry strategies - **Cloud & Infra:** AWS EC2, ALB, Route 53, Lambda, SES, SQS, S3, CloudFront, Docker, Git - **Architecture:** REST APIs, Webhooks & signature validation, Event-driven systems, Idempotency & retries, Wallet & ledger design, Subscription lifecycle, RBAC / CASL policies - **Integrations:** Razorpay, Cashfree, Centrobill, Shopify, Onfido, Delhivery, Shiprocket, ONDC, Firebase, WhatsApp API, Slack - **Testing & Observability:** Jest, Supertest, OpenTelemetry, Signoz, New Relic, Winston, Pino, Swagger - **AI-Assisted Development:** Claude, GitHub Copilot, ChatGPT ## Core competencies - Back-end development & architecture - Distributed & event-driven systems - Real-time infrastructure - API, webhook & third-party integration - Payment & subscription lifecycle - Database design & performance - Multi-tenant platform engineering - Wallet, ledger & transaction processing - Cloud infrastructure (AWS) - Background jobs & async workflows - Production reliability engineering - Code review, mentoring & ownership - Stakeholder engagement ## Achievements - **Star Performer — 2024 & 2025** — AppOctet Technologies. Recognised in consecutive years for product delivery and back-end performance work. - **First Rank — B.Sc. Computer Science** — Mumbai University. Graduated first in the Computer Science programme at Ismail Yusuf College. - **ONDC Network Certification** — Open Network for Digital Commerce. Led a logistics integration through ONDC protocol certification with 5+ partner organisations. ## Education - B.Sc. Computer Science, Ismail Yusuf College, Mumbai University (2019 — 2022) — First Rank ## Certifications - Generative AI Mastermind — OutSkill - Associate in IT Foundation Skills (Java) — Infosys Springboard (May 2022): https://hussainansari.dev/certificates/infosys-springboard-it-foundation-skills-java.pdf - Advanced Java Programming — LinkedIn Learning (Apr 2022): https://hussainansari.dev/certificates/linkedin-learning-advanced-java-programming.pdf - Problem Solving (Basic) — HackerRank - Algorithm Essentials — CHM College, Ulhasnagar (Jul 2021) - AI Tools Workshop — Be10x # Case studies ## Case study: Creator Subscription & Wallet Platform URL: https://hussainansari.dev/work/subscription-wallet-platform Client: Creator subscription platform · Employer: INK IN CAPS · Period: Dec 2025 — Present · Role: Software Development Engineer 2 Real-time messaging, subscription lifecycles, and a multi-provider wallet and ledger, run across a horizontally scaled NestJS monorepo. **Outcomes:** 3,000+ concurrent WebSocket connections; $462K/mo processed across ~7,700 transactions; 30K+ users served; −75% home-feed load time; −90% home-feed payload size ### Problem The platform sells subscriptions and pays out creator earnings, so two things have to be true at once: chat and notifications need to feel instant across many server instances, and every rupee moving through checkout, renewal, or payout needs to land exactly once — no duplicate charges, no dropped renewals, no earnings that vanish on a retry. ### Architecture The back end is a NestJS 10 monorepo: five deployable apps — core, admin, agency, auth-server, notifications — over seven shared libraries covering auth (JWT per audience plus CASL policy guards), wallet and transaction handling, agency-side transactions, PDF generation, and signed CDN asset URLs. MongoDB (Mongoose 7, snake_case fields, additive-only schema changes — no migration framework) holds the data; Redis and BullMQ carry every background job. Roughly 28 domain modules live under core — posts, stories, channels, groups, feeds, shops, payouts, moderation, complaints, a partner API lane, and payment tracing among them — which is a lot of surface for one service, so the boundaries that matter are the ones drawn around money, media, and real-time rather than around individual features. ### Real-time Sockets are authenticated at the handshake, before a connection can join any room — an unauthenticated socket never reaches a handler. Beyond that boundary sit two stateful handlers, both keeping their state in Redis rather than in process memory, because any instance may serve any user. - Presence tracks multiple concurrent sessions per user — the same account on a phone and a laptop is one presence, not two — across online-public, online-private and live states, with a preference to hide status entirely. Sessions are re-synced and verified on boot so a restarted instance doesn't leave ghosts online. - Live streams hold a viewer set per stream, aggregate reactions through a throttle so a burst of taps doesn't become a burst of emits, and expire on two timers: an idle auto-expire and a longer graceful window for a stream that drops mid-broadcast. - The Redis adapter republishes every emit to sibling instances, so a user connected to one server receives events raised on another. That is what makes the socket tier horizontally scalable instead of sticky. - Notifications branch two ways from the same event: Firebase multicast for device push, and a persisted store backing in-app read/unread counts and acknowledgement. ### Async & queues Every slow or failure-prone operation runs on BullMQ rather than in the request path. The topology is deliberately wide — twelve-plus dedicated queues rather than one general worker — because the queues are separated by failure domain, not by convenience. - Media: asset-optimizer and a separate image/audio lane, so a large video transcode can't sit in front of an avatar resize. - Money: wallet transactions on their own queue, isolated from anything that could back it up. - Messaging: message, response, and unread-message-count queues on a separate Redis connection from the main lane. - Platform: event bridge, scheduled task, channel, and cron; plus security-email and account-email split apart so a marketing backlog can never delay a password-reset mail. - The reason for the split is operational: a stuck media job must not delay a subscription renewal. One shared worker pool makes that failure mode unavoidable; separate queues make it a non-event. ### Key decisions - **Idempotency at the money boundary:** Checkout unifies five payment paths — card, two SEPA/iDEAL providers, a legacy gateway, and an internal wallet — behind one endpoint, with each provider's webhook signature-verified independently before it can touch a transaction. Renewals and retries are guarded so a webhook replay or a retried job can never double-charge or double-credit. - **Wallet as two buckets, not one:** Spendable balance and locked (escrowed) creator earnings are separate fields, moved between by a scheduled release job rather than by application logic reaching into both. That separation is what makes a partial refund, a chargeback, or a wallet-first purchase safe to reason about independently. - **Queues own everything slow:** Renewal processing, invoice generation, and notification delivery all run through BullMQ rather than inline in the request path, so a slow downstream call (a payment provider, an email service) never holds open an HTTP response. ### Stack - **Service:** NestJS 10, TypeScript, MongoDB, Mongoose 7, Monorepo (5 apps, 7 libs) - **Real-time:** Socket.IO, Redis adapter, Redis Pub/Sub, Presence, Live streams - **Async:** BullMQ, Redis, 12+ dedicated queues, Cron - **Auth:** JWT per audience, CASL policy guards, Socket handshake auth, Webhook signature guards - **Notifications:** Firebase multicast, In-app store, Transactional email - **Media:** S3, sharp, ffmpeg, Automated moderation, Signed CDN URLs - **Cloud:** AWS EC2, ALB, Route 53, Lambda, SES, S3 --- ## Case study: Multi-Tenant Seller Marketplace URL: https://hussainansari.dev/work/seller-marketplace Client: Brownliving · Employer: AppOctet Technologies · Period: 2022 — 2025 · Role: Backend Lead Seller operations, order management, and Shopify synchronisation for a multi-tenant marketplace, rebuilt on NestJS with a migration of 800+ sellers and zero data loss. **Outcomes:** 800+ sellers migrated, zero data loss; 2.7M records re-indexed; −25% query latency ### Problem The marketplace runs hundreds of independent sellers on one platform — each with their own products, orders, subscriptions, and payout terms — synced against Shopify as the storefront of record. The existing system had grown organically; migrating it onto a new schema without breaking a single seller's live orders, and without the query latency that comes with millions of rows across shared tables, was the core problem. ### Architecture NestJS with TypeORM over MySQL for the transactional core, MongoDB for a subset of flexible document data, and a dedicated sync layer reconciling seller catalogues and orders against the Shopify Admin API via webhooks. Inbound Shopify data lands in a raw dump table before it is mapped into live order entities, so a re-run of a sync stages rather than corrupts — the staging table is the idempotency boundary. A status mapper translates Shopify's and each carrier's own vocabulary into one internal order-status model, which is what keeps the rest of the system from growing per-integration conditionals. Carriers themselves are modelled as data — a shipping-partner entity plus a per-seller onboarded-partner join — so adding one is configuration rather than a branch. Role-based access control is modelled directly in the schema (userRole / userPermission entities) rather than bolted on, so the same authorization path serves sellers, staff, and admin. ### Key decisions - **Migrate seller-by-seller, not table-by-table:** 800+ sellers — products, orders, and subscriptions — were moved with full validation per seller rather than a single big-bang schema cutover, so a bad record surfaced against one seller instead of failing the whole migration. - **Index for the queries that actually run:** Schema and indexing were reworked against real query patterns across roughly 2.7 million records, cutting query latency by 25% — the kind of gain that only shows up once you profile production traffic rather than guess at indexes upfront. - **Payments split by purpose:** Razorpay handles subscription billing; Cashfree handles invoice payments and automated seller settlements — two different money paths kept deliberately separate rather than forced through one abstraction. - **Instrument before optimising:** OpenTelemetry was wired in with a custom interceptor and a tracer decorator that could be dropped onto specific methods, feeding Signoz. That is what turned the latency work from guesswork into targeted fixes — the 25% figure is measured against traces, not inferred from a stopwatch. - **Long-running reports leave the request path:** Seller exports run through a dedicated queue with its own entities, so generating a large report is a job with a status a seller can poll rather than a request that times out. ### Stack - **Service:** NestJS, TypeScript, MySQL, TypeORM, MongoDB - **Commerce:** Shopify Admin API, Webhooks, Staged sync + dump table - **Payments:** Razorpay, Cashfree - **Logistics:** Delhivery, Shiprocket, Multi-carrier abstraction - **Async:** Export queue, Scheduled tasks - **Observability:** OpenTelemetry, Signoz, Custom tracer decorator - **Cloud:** AWS SQS, SES, S3, Secrets Manager --- ## Case study: Events & Booking Platform URL: https://hussainansari.dev/work/events-booking Client: PlayAce · Employer: AppOctet Technologies · Period: 2022 — 2025 · Role: Backend Owner Event creation, participant management, and payouts for a bookings platform, with identity verification and real-time admin alerting. **Outcomes:** −40% admin response time; 5 notification channels from one backend; 3 clients served: web, native, admin ### Problem Booking platforms live or die on trust: organisers need to get paid reliably, participants need identity verification before high-value events, and admins need to know when something needs attention without refreshing a dashboard all day. ### Architecture An Express and MongoDB service backing both a React web client and a React Native app. The domain is wider than 'events': hosts submit event requests that move through an approval workflow, participants join and are managed per event, hosts are paid out, and the whole thing is wrapped in a growth layer — influencers with their own trackable coupons, generic coupon campaigns, ad banners, brand placements, and newsletters. Reviews are collected after the fact by a scheduled job rather than prompted inline. Razorpay handles payouts, refunds, and participant transactions; Onfido verifies identity with webhook-driven status updates rather than polling; media goes to S3. Notification delivery is split across dedicated controllers per channel — SendGrid for email, WhatsApp, and Slack — and further scheduled jobs handle address normalisation and geocoding. ### The mobile client The same backend serves a React Native app shipped to both stores, which is where most participants actually book. Payments and identity run through native SDKs rather than web views — Razorpay's native checkout and Onfido's native capture flow — because document capture and payment authorisation both degrade badly in an embedded browser. - Firebase across three roles: analytics, push messaging, and Crashlytics for field crash reporting. - i18next for localisation, Reanimated and a native gesture stack for the interaction work. - Shipping one product across a web client, a native app, and the backend behind both meant API changes had to stay compatible with a store-review release cycle — the app can't be redeployed on demand the way the web client can. ### Key decisions - **Webhook-driven verification, not polling:** Onfido KYC status updates arrive as webhooks and update participant state directly, removing the need for the client or a cron job to poll for verification results. - **Push the alert to where admins already are:** Routing operational alerts into Slack in real time — rather than a page they had to check — cut admin response time by 40%. ### Stack - **Service:** Express.js, MongoDB, Node-cron - **Payments:** Razorpay, Payouts, Refunds - **Identity:** Onfido KYC, OTP - **Notifications:** SendGrid, Firebase, WhatsApp API, SMS, Slack - **Mobile:** React Native, Razorpay SDK, Onfido SDK, Firebase, i18next, Reanimated - **Web:** React, Redux - **Cloud:** AWS S3 - **Observability:** New Relic, Winston --- ## Case study: ONDC Logistics Network Integration URL: https://hussainansari.dev/work/ondc-logistics Client: Logistics aggregator · Employer: AppOctet Technologies · Period: 2022 — 2025 · Role: Integration Lead Protocol-compliant order, fulfillment, and grievance APIs certifying a logistics provider onto India's Open Network for Digital Commerce. **Outcomes:** 5+ partner organisations certified; 16 protocol services across 4 domains; 100% of order lifecycle stages audited ### Problem ONDC is a shared, government-backed protocol for e-commerce — joining it means implementing a specification exactly, not just building an API that works for one client. Every participant on the network has to interoperate with every other participant's implementation, and certification requires proving that against real partner traffic. ### Architecture NestJS and TypeORM over MySQL, structured around the ONDC protocol's own domains rather than around the business. Pre-order covers search, quotation (the pricing step behind /select), init, confirm, and BPP fulfillment. Post-order covers order, status, fulfillment status, tracking, cancellation, updates, and support. IGM handles grievances as issue and issue-status flows, and RSP handles receiver-side reconciliation. Every inbound request is cryptographically signature-verified before it reaches any business logic, and a trio of stage, transaction-stage, and transaction services record each step of an order's protocol lifecycle so the whole exchange is reconstructable after the fact. The piece that made this tractable is a separate adapter layer sitting between the protocol surface and the aggregator's own carrier API, with its own exception filter and logging interceptor. Protocol vocabulary lives on one side of that boundary and the carrier's existing API on the other. Without it, ONDC compliance would have meant rewriting a working logistics platform to speak a new dialect; with it, certification became an integration problem instead of a migration. ### Key decisions - **Build to the spec, verify against partners:** Rather than integrate against one counterparty, the work meant implementing the protocol generically and then certifying it in practice with 5+ partner organisations, since ONDC compliance is defined by interoperability, not a single integration test. - **Audit trail as a first-class concern:** Stage and transaction-stage services plus daily-rotated audit logging exist because a protocol built for regulatory-grade commerce needs every state transition traceable after the fact, not just at request time. When a partner disputes what was sent, the answer has to be retrievable months later. - **Translate at the edge, don't rewrite the core:** An adapter layer with its own error handling and logging maps between ONDC's vocabulary and the carrier's existing API. Keeping the translation at the boundary meant the logistics platform underneath never had to become ONDC-shaped — which is why the integration shipped at all. ### Stack - **Service:** NestJS, TypeScript, MySQL, TypeORM - **Protocol:** ONDC, Signature verification, Registry, Pre-order, Post-order, IGM, RSP - **Integration:** Carrier API adapter, Exception filter, Logging interceptor - **Observability:** Winston, Daily-rotate audit logs, Transaction-stage tracking --- ## Case study: Offline-First Rider App URL: https://hussainansari.dev/work/rider-delivery-app Client: Logistics aggregator · Employer: AppOctet Technologies · Period: 2022 — 2025 · Role: Mobile Developer A React Native delivery app for riders working without reliable connectivity, built on a local SQLite source of truth and a sync engine that routes each shipment by type and outcome. **Outcomes:** 100% of a shift capturable offline; 4 shipment flows, 8 settlement routes; 4 locales shipped ### Problem Delivery riders lose connectivity constantly — basements, stairwells, lifts, rural routes. An app that needs the network to record a delivery is an app that blocks a rider mid-route, and a shipment outcome lost to a failed request is a package the system still believes is in transit. The requirement was not graceful degradation but genuine offline operation: a full shift's work captured with no signal at all, then reconciled without duplicating or dropping a single outcome. ### Architecture The on-device SQLite database is the source of truth, not a cache. Seven tables — shipments, orders, shipment details, product images, product attributes, QC questions and QC answers/images — hold everything a rider produces during a shift, and every action is written locally and stamped with a sync status before the interface acknowledges it. Nothing in the UI waits on a request. When connectivity returns, a sync engine walks the pending shipments and dispatches each one on a two-dimensional key: shipment type and outcome. First mile, last mile, RTO and reverse pickup each settle through a different endpoint, and each has a distinct success and failed-attempt path — eight routes in total, because a failed pickup and a failed delivery are not the same event and neither resembles a completed one. Every dispatch carries its own success and failure callback, so a record that fails to sync stays pending and the rest of the queue drains past it. ### Key decisions - **Local-first, sync-later:** SQLite is treated as the system of record on-device rather than a read cache in front of the API. That inverts the usual mobile data flow: the network is a background reconciliation concern, not a precondition for the rider finishing a job. - **Route by type and outcome, not through one generic queue:** A single 'sync pending items' endpoint would have collapsed genuinely different settlements into one payload shape. Instead the engine dispatches on shipment type crossed with outcome, because each combination carries different evidence — manifest images and a signature for a pickup, signature and cash-collection proof for a delivery, QC question answers and photo sets for a reverse pickup. - **Evidence capture belongs in the offline path:** Barcode scanning, signature capture, QC photo sets and COD/UPI collection all persist locally alongside the shipment they belong to. Proof of delivery captured offline is worthless if it can't be tied back to the right record on sync, so the images are stored as rows against the shipment rather than as loose files. - **Ship fixes without waiting on store review:** CodePush checks for an update on app start. For a workforce app where a bug can strand riders mid-route, a two-day store review is not an acceptable turnaround for a hotfix. - **Built for the people actually using it:** Four locales — English, Hinglish, Hindi and Marathi, roughly 500 strings each. The users are working riders, and Hinglish in particular exists because romanised Hindi is what a lot of them actually read fastest. ### Stack - **App:** React Native, Redux, React Navigation - **Local data:** SQLite, AsyncStorage, Custom sync engine - **Capture:** Barcode scanning, Signature capture, Camera, Image compression - **Device:** Background geolocation, Background actions, Netinfo, Haptics - **Delivery:** CodePush OTA, Firebase messaging, Crashlytics - **Localisation:** i18next, English, Hinglish, Hindi, Marathi