Engineering a Lightweight Request Architecture for Local Retailers
Technical notes on building a fast, low-overhead event dispatch system connecting mobile clients across variable network conditions.
Designing a system that operates reliably between consumers and non-technical merchants requires engineering for resilience, simplicity, and low latency.
System Architecture
The Vipto platform architecture is decoupled into three primary tiers: client applications (Customer and Seller mobile apps), an API gateway managing authentication and rate-limiting, and an event-driven request coordination service.
When a customer initiates an availability query, the request is validated, timestamped, assigned a cryptographic request ID, and routed to the merchant's registered device token via low-latency push queues.
// Core Availability Request Payload
interface AvailabilityRequest {
id: string;
customerId: string;
storeId: string;
productId: string;
requestedAt: number; // Unix timestamp
expiresAt: number; // Auto-expiry window (e.g., +30 mins)
status: 'PENDING' | 'AVAILABLE' | 'NOT_AVAILABLE' | 'EXPIRED';
proximityKm: number;
}Geospatial Query Strategy
To keep spatial queries fast and avoid heavy database locking, we utilize precision-based geohashing. Stores are indexed into hierarchical bounding boxes, allowing the server to retrieve relevant neighborhood listings in single-digit milliseconds without computationally expensive polygon calculations on every mobile request.
Notification Pipeline
Reliability in push messaging is critical. If a merchant's device is temporarily sleeping or background-restricted by the operating system, the system falls back to a persistent WebSocket channel on next app wake, ensuring no customer inquiry is silently dropped.
Every request payload is self-contained. If network connectivity drops mid-session, the client queues state transitions locally and synchronizes atomically upon reconnect.
Data Integrity & Privacy
Customer personal details (such as phone numbers or exact residential coordinates) are never shared with merchants during an availability request. The merchant receives only the product inquiry and an approximate walking distance, safeguarding customer privacy at every step.