Skip to main content
Mobile Applications Β· Social

TrulyMadly

Dating app and website with ML matchmaking, PostGIS location discovery, WebSocket chat and automated face verification.

TrulyMadly product cover

TrulyMadly overview

We built a feature-rich dating app and website platform for TrulyMadly, designed to support a very large concurrent user base with minimal latency across native iOS, native Android and standard web browsers. The engagement covered the full product lifecycle: requirement analysis, detailed UI prototyping, agile product sprints, quality assurance testing and multi-region deployment.

The delivered system is a set of containerised microservices behind an Envoy Proxy API gateway that handles rate limiting and SSL termination. An authentication service backed by Okta and JSON Web Tokens, a matchmaking service driven by machine learning, a location discovery service on PostgreSQL with PostGIS and a real-time chat service on WebSockets each run in their own partition, with Apache Kafka streaming interaction events to the scoring models and Redis serving as cache and Pub/Sub broker. That separation lets heavy work such as model scoring scale independently from light requests such as profile text updates, and it removed the single points of failure that had constrained the previous platform.

Challenge in Social operations

The legacy infrastructure was a monolithic backend that coupled user authentication, chat routing and matchmaking computation into a single database instance. When thousands of users ran location-based queries at the same time, the main database suffered massive write locks and thread exhaustion. Profile images were stored and processed directly on the primary application servers, so disk space and network bandwidth ran out during peak hours and image uploads slowed. Real-time chat depended on basic polling rather than persistent connections, producing heavy overhead and delayed notifications, and the whole system showed high CPU utilisation and frequent timeouts at moments of maximum user interaction.

The targets we set for the rebuild were specific: global API latency below one hundred milliseconds, a 99.99% availability standard, discovery feeds refreshing in under half a second, push notifications arriving within milliseconds of a match event, and a strict zero-trust data perimeter. Every microservice had to remain stateless, carrying user state in secure tokens rather than server memory, so that any single cloud node could fail without breaking active sessions.

Solution architecture & delivery

The matchmaking engine continuously gathers interaction events (profile skips, likes, message frequency) into an Apache Kafka pipeline that feeds collaborative filtering models. These recalculate compatibility scores in the background and refresh discovery queues without adding latency to the interface. Location discovery uses PostGIS extensions to index coordinates in spatial bounding boxes, converts latitude and longitude into geo-hashes so distance filtering becomes a string prefix query, and answers radial searches for the user's chosen five, ten or twenty kilometre radius in milliseconds. Coordinate updates from moving devices are batched through an asynchronous cache rather than written directly to the database.

Chat runs over full-duplex WebSocket sessions held by a distributed Node.js cluster. A connection manager broadcasts each message across a Redis Pub/Sub fabric so it reaches whichever server node holds the recipient's active connection. Photos and videos never pass through the chat servers: the client requests a short-lived pre-signed URL and uploads directly to cloud object storage. For offline recipients, message metadata goes to a push service that formats payloads for Firebase Cloud Messaging and Apple Push Notification service, with automated retry and exponential backoff. Profile verification triggers on every new account and photo change: an automated computer vision service runs facial landmark matching and liveness checks, and any flagged profile is routed to a custom manual verification dashboard for human review. Sign-in requires a one-time passcode over an SMS gateway, after which the identity service issues short-lived, cryptographically signed JSON Web Tokens under a rotation policy, with native mobile biometric login supported. Premium features and subscriptions are unlocked through a transactional state machine that verifies payment webhooks from Apple, Google or Stripe, so no card data is stored on the platform.

Infrastructure is defined in Terraform and runs as Docker containers on Kubernetes across AWS and Azure, with Envoy Proxy and AWS API Gateway at the edge, AWS Shield for DDoS protection and CrowdStrike Falcon for runtime threat detection. Every storage volume, database instance and media bucket uses AES-256 encryption with automatically rotated cloud-managed keys; external traffic is TLS 1.3 only. Real names, phone numbers and physical coordinates live in isolated tables and are replaced by anonymous tokens during matching so the models never see identity data, and automated scrubbing workflows delete personal information on request. Each microservice runs under a limited service account, so the messaging service, for example, has no path to the payment databases, and administrators reach production only through centralised identity with hardware MFA tokens and role-based access lists. Kubernetes scales pods on CPU and memory, load balancers steer traffic away from saturated nodes, and a multi-region active-passive disaster recovery design pairs synchronous in-zone replicas with asynchronous cross-region replication, automated database promotion and DNS re-routing, with clients restoring sessions from the mirrored token cache. GitHub Actions runs unit tests, syntax checks and dependency vulnerability scans on every commit, ArgoCD applies GitOps rolling upgrades one instance at a time, and Prometheus, Grafana and the ELK stack collect metrics and logs from every pod.

Key features of TrulyMadly

  • Machine learning matchmaking engine fed by Apache Kafka interaction streams, recalculating compatibility scores in the background
  • Location discovery on PostgreSQL with PostGIS, geo-hashing and bounding-box radial queries for 5, 10 and 20 km ranges
  • Real-time text and multimedia chat over WebSockets on a Node.js cluster with Redis Pub/Sub routing and pre-signed direct-to-storage media uploads
  • Push notification service for matches and messages via Firebase Cloud Messaging and APNs with retry and exponential backoff
  • Automated face verification with facial landmark matching and liveness checks, plus a custom manual review dashboard for flagged profiles
  • SMS one-time-passcode multi-factor sign-in, rotated short-lived JWTs and native biometric login
  • Premium subscription and in-app purchase state machine verifying Apple, Google and Stripe payment webhooks
  • Envoy API gateway with rate limiting, tokenised personal data, per-service least-privilege accounts and multi-region active-passive disaster recovery

Who this mobile application is for

This platform is built for consumer dating and Social discovery products that must serve large numbers of simultaneous users on iOS, Android and web, where every swipe, search and message has to feel instant and where trust depends on verified profiles and protected personal data. The same architecture applies to any location-aware Social app with real-time messaging, recommendation models and premium subscriptions.

Impact & results

  • Monolithic backend with a single shared database replaced by independently scaling authentication, matchmaking, location and chat microservices
  • Polling-based chat replaced by persistent WebSocket sessions with cross-server delivery through Redis Pub/Sub
  • Image and video traffic moved off application servers to cloud object storage via pre-signed URLs
  • Location searches served from PostGIS indexes and geo-hashes in milliseconds instead of per-profile distance calculations
  • Fake accounts screened by automated facial and liveness verification before reaching manual review
  • Rolling GitOps deployments with zero downtime and a multi-region active-passive recovery design targeting zero data loss

FAQ about TrulyMadly

What problem did the TrulyMadly rebuild solve?

TrulyMadly's legacy backend was a monolith that coupled authentication, chat routing and matchmaking into one database instance. Simultaneous location queries caused write locks and thread exhaustion, profile images stored on the application servers exhausted disk and bandwidth at peak, and chat relied on polling rather than persistent connections. We moved the platform to isolated microservices on Kubernetes with PostGIS location search, WebSocket messaging, Kafka-fed machine learning matchmaking and object-storage media uploads across native iOS, native Android and web.

Which technologies power TrulyMadly?

Node.js WebSocket services and a Redis Pub/Sub broker handle real-time chat; PostgreSQL with PostGIS and Redis store profiles, geospatial data and session tokens; Apache Kafka streams interaction events to the machine learning scoring models. Envoy Proxy and AWS API Gateway manage ingress, Okta and JSON Web Tokens handle identity, Firebase Cloud Messaging and APNs deliver push, and everything runs in Docker on Kubernetes across AWS and Azure, provisioned with Terraform and deployed through GitHub Actions and ArgoCD, with Prometheus, Grafana and the ELK stack for observability.

How does location-based matching stay fast for thousands of concurrent users?

User coordinates are indexed with PostGIS spatial bounding boxes and converted into geo-hashes, which turns distance calculations into low-overhead string prefix queries. Radial range queries return profiles within the chosen five, ten or twenty kilometre radius in milliseconds, and coordinate updates from moving devices are batched through an asynchronous cache so they never create direct database write locks.

How does TrulyMadly keep fake profiles off the platform?

Every new account and every photo change is passed to an automated computer vision service that runs facial landmark matching and liveness checks and compares the verification selfie with the public profile photos. Accounts that fail are locked and routed to a custom manual review dashboard for human inspection. Sign-in requires a one-time passcode delivered by SMS, after which the identity service issues short-lived, rotated JSON Web Tokens, with native biometric login supported on mobile.

TrulyMadly product screens

Build your next Social product with Next Olive

Share your requirements β€” we will propose scope, timeline and stack within one business day.