GeoMatch: A high-Load
geolocation-based user
matching application
A geolocation-based service that matches users based on
their geographic metadata.
Requirements
● Supports 10M of registered accounts.
● Has irregular traffic (peak traffic on weekends and evenings)
● Read-heavy Application: (write/read Ratio: 1:22)
This application is read-heavy, with a typical write-to-read ratio of 1:22. Each user shares their geo
metadata once, triggering the application to find matches. Users typically spend about 15 minutes per
session, scrolling through 30 profiles per minute (2 seconds per one profile), leading to 450 reads per
single write. When matches are displayed in batches (e.g., 20 profiles at a time), the ratio adjusts to 1
write for every 22 reads.
● Every 30th user is online at a peak time. So we expect 333333 users online.
● Users upload 5 photos and write about 250 characters in their profile description.
Back-to-envelope
● Photos memory consumption – 5 photos per user (compressed to 2MB) → 10M*5*2MB=100TB
● Text memory consumption – 250 characters per user for description → 250 bytes per user → 10M
users = 2.5GB.
● Metadata memory consumption – 500 bytes of geo metadata per user → 10M users = 5GB.
● 40 seconds of scrolling per one batch of 20 matched users → 1 request in 40 seconds (write request)
→ RPS = 1/40 = 0.025 r/s from one user → for 333333 users online = 333333*0.025 = 8333 r/s.
Also 10000 requests per second for log-ins and log outs -> 18333 r/s.
● Reliability
● Maintainability
● Scalability in peak times
● Show at leas timeline on faults.
Data storage
● NoSQL Database with Geo modules (e.g., MongoDB, DynamoDB).
○ Human-readable data
○ No relationships by ID that slow down searches and joins
○ Easy scalability
○ Flexible schema changes
○ Simple geolocation-based searches
Data storage requirements
● Replications
○ Ensures availability and load balancing.
○ Replicas distributed globally for performance.
● Partition
○ Improves performance by distributing data across servers.
○ Simplifies horizontal scalability.
● Transactions
○ Read Committed to prevent dirty reads while balancing performance.
● Consistency
○ Casual consistency for geo-matching operations.
● Consensus
○ Raft consensus algorithm for critical operations.
Metrics
● Key metrics
○ Response time of matching service (<500ms).
○ Search duration (<300ms).
○ CPU and Memory Load with alerts at 80% (warning alert) and 95% (critical alert) thresholds.
■ Critical alert → pager call to the responsible person
○ Number of database replicas, CPU/Memory load of workers for information reasons.
● Business metrics
○ Count of location-based searches
○ Count of user selections per session
Basic architecture
GeoMatch allows users to connect through mobile and web apps, processing requests via a central API. The
backend handles core user flows and delegates match suggestions to a specialized microservice. To ensure
scalability and reliability, the system requires 41 server replicas, capable of handling 18,333 requests per
second at peak load:
● One BE server can handle 500 r/s.
● 18,333 requests per second at peak load
● 18333/500 = 36 replicas → with buffer 15% → 41 replicas
High-level architecture
Low-level architecture of main BE service
