Skip to main content

Solvice Maps: Technical Architecture

Architecture Overview

Solvice Maps implements a sophisticated, cloud-native microservices architecture designed for high performance, scalability, and reliability. The system combines multiple routing engines with intelligent request processing, caching, and optimization to deliver sub-50ms routing calculations at enterprise scale.

System Architecture Diagram

Core Components

1. MapR Gateway (Primary API Service)

Technology Stack:
  • Framework: Quarkus (Java/Kotlin)
  • Language: Kotlin 1.9 with JVM 17
  • Database: PostgreSQL with Hibernate ORM
  • Authentication: JWT (HS256) tokens
  • Messaging: Google Cloud Pub/Sub
Responsibilities:
  • Primary API endpoint for all routing requests
  • Request validation, authentication, and rate limiting
  • Intelligent request splitting for large matrices
  • Content-based caching and deduplication
  • Multi-engine routing coordination
  • Result aggregation and response formatting
Key Architectural Patterns:
  • Layered Architecture: Controllers → Services → Repositories
  • Event-Driven Processing: Pub/Sub for asynchronous operations
  • Proxy Pattern: Dynamic client creation for external APIs
  • Circuit Breaker: Fault tolerance for external services

2. OSRM Integration Service

Technology Stack:
  • Framework: NestJS (Node.js/TypeScript)
  • Runtime: Node.js 22 with clustering
  • OSRM: Native C++ bindings (Project-OSRM)
  • Load Balancing: Weighted round-robin
  • Deployment: Google Kubernetes Engine
Responsibilities:
  • Direct integration with OSRM routing engines
  • Traffic slice management (time-dependent routing)
  • Interpolation for smooth traffic transitions
  • High-performance routing calculations
  • Pub/Sub message processing for batch operations
Advanced Features:
  • Multi-Instance Management: Load multiple OSRM instances per region
  • Traffic Slice Interpolation: Decimal slice support (e.g., 2.3, 4.7)
  • Memory Optimization: Memory-mapped files for OSRM data
  • Batch Processing: Configurable concurrency limits

3. Infrastructure Layer

Cloud Platform: Google Cloud Platform (GCP)
  • Compute: Google Compute Engine with Container-Optimized OS
  • Container Orchestration: Google Kubernetes Engine (GKE)
  • Load Balancing: Global HTTP(S) Load Balancer
  • Storage: Cloud Storage for large results
  • Messaging: Cloud Pub/Sub for event processing
  • Monitoring: Cloud Monitoring with custom metrics

Data Flow Architecture

1. Synchronous Request Flow (Routes, Small Tables)

2. Asynchronous Request Flow (Large Tables, Cubes)

3. Caching and Optimization Flow

Routing Engine Integration

Engine Architecture

Multi-Engine Support:
Implemented Engines:
  • OSM/OSRM: Self-hosted, high-performance, free
  • TomTom: Commercial API with real-time traffic
  • AnyMap: European-focused routing service
  • Google Maps: Global coverage with comprehensive data

Engine Selection Logic

Automatic Engine Selection:
Selection Criteria:
  1. Geographic Coverage: Engine support for request region
  2. Request Size: Engine limits and capabilities
  3. Performance Requirements: Response time vs. accuracy
  4. Cost Optimization: Usage-based routing decisions

Traffic Slice Management

Time-Dependent Routing:
  • Integer Slices (0-12): Direct OSRM instance calls
  • Decimal Slices (2.3, 4.7): Linear interpolation between adjacent slices
  • Traffic Patterns: Different profiles for weekdays vs. weekends
  • Real-time Selection: Current time-based slice selection
Interpolation Algorithm:

Database Architecture

Schema Design

Core Entities:
Indexing Strategy:
  • Hash-based lookups: B-tree index on content hash
  • Status queries: Index on (status, created_at)
  • Hierarchical queries: Index on parent_id for request splitting

Data Storage Strategy

Hot Data (PostgreSQL):
  • Request metadata and status
  • Small responses (< 1MB)
  • User authentication and rate limiting data
Cold Data (Cloud Storage):
  • Large matrix results (> 1MB)
  • Binary OSRM data files
  • Historical analytics data

Performance Architecture

Performance Targets

Response Time SLAs:
  • Simple Routes: < 50ms P95
  • Small Tables (< 100 coords): < 100ms P95
  • Large Tables: Asynchronous processing
  • API Overhead: < 10ms for cached responses

Optimization Strategies

1. Request Splitting:
2. Content-Based Caching:
3. Parallel Processing:

Scalability Architecture

Horizontal Scaling

Stateless Services:
  • All services designed for horizontal scaling
  • No local state storage
  • Session data in external stores (PostgreSQL, Redis)
Auto-Scaling Triggers:
  • CPU utilization > 70%
  • Request queue depth > 100
  • Response time P95 > SLA threshold
Load Distribution:

Event-Driven Scaling

Pub/Sub Message Processing:
  • Dynamic subscription scaling based on queue depth
  • Weighted round-robin message distribution
  • Dead letter queues for failed processing
Asynchronous Processing Benefits:
  • Decouples API response time from computation time
  • Natural backpressure handling
  • Enables batch optimization strategies

Security Architecture

Authentication & Authorization

Multi-Layer Security:
JWT Token Structure:

Data Protection

Encryption:
  • In Transit: TLS 1.3 for all API communication
  • At Rest: Google Cloud Storage encryption
  • Database: PostgreSQL transparent data encryption
Access Controls:
  • Service Accounts: GCP IAM with minimal permissions
  • Network Segmentation: VPC isolation
  • Secrets Management: Google Secret Manager

Monitoring and Observability

Metrics Collection

Custom Metrics:
Infrastructure Metrics:
  • Request throughput and latency
  • Database connection pool utilization
  • Memory and CPU usage per service
  • External API response times and error rates

Distributed Tracing

OpenTelemetry Integration:

Health Monitoring

Health Check Endpoints:
  • /health/live: Basic service liveness
  • /health/ready: Service readiness (dependencies available)
  • /health/engines: Routing engine status
  • /health/database: Database connectivity

Error Handling and Resilience

Circuit Breaker Pattern

Retry Strategies

Exponential Backoff:

Graceful Degradation

Fallback Mechanisms:
  1. Engine Fallback: Switch to alternative routing engine
  2. Cached Response: Return stale cached data with warnings
  3. Simplified Response: Return basic distance calculations
  4. Error Response: Structured error with retry guidance

Data Consistency and Reliability

Event Sourcing for Request Tracking

Event Log:

Idempotency

Idempotent Request Processing:

Development and Deployment Architecture

CI/CD Pipeline

Automated Deployment:

Blue-Green Deployment

Zero-Downtime Deployments:
  1. Deploy new version to blue environment
  2. Run health checks and integration tests
  3. Switch load balancer to blue environment
  4. Monitor for issues, rollback if necessary
  5. Decommission green environment
This technical architecture provides a robust foundation for Solvice Maps, enabling high performance, scalability, and reliability while maintaining developer productivity and operational simplicity.