Skip to main content

​
Architectural Design

​
Data Handling Strategy

Real-Time API Fetching (Preferred) – Avoca’s architecture is optimized for real-time data operations. We prefer to fetch the following data types directly from your APIs in real time:
  • Live availability – Appointment slot availability
  • Dynamic pricing – Current service pricing and promotional offers
  • Instant confirmations – Immediate booking confirmations and updates
  • Customer account status – Current customer information and preferences
  • Service eligibility – Eligibility checks based on current business rules
  • Booking modifications – Updates for cancellations, reschedules, and changes
Local Caching (Strategic) – We implement intelligent caching for performance optimization on the following data types:
  • Static service catalogs – Service descriptions, categories, and relatively stable metadata (TTL configurable, typically 1–24 hours)
  • Business operating hours – Standard operating schedules (refreshed daily or on demand)
  • Provider profiles – Service provider information and credentials (TTL configurable)
  • Frequently accessed reference data – ZIP codes, service areas, common appointment types
Our caching strategy includes:
  • Configurable Time-To-Live (TTL) values per data type
  • Cache invalidation webhooks for immediate updates when source data changes
  • Automatic cache refresh mechanisms
  • Fallback to real-time API calls if cached data is stale or unavailable

​
Azure Region Preferences

Primary Considerations – Given that your APIs will be hosted in Azure, our preferences are: Data Residency & Compliance
  • We defer to your organization’s data residency requirements for healthcare/customer data
  • Our infrastructure (AWS-based) can integrate with any Azure global region
  • For US-based operations, we recommend Azure US East regions for optimal latency to our primary AWS US infrastructure
Latency Optimization
  • Target API response time: under 200 ms for availability checks, under 500 ms for booking operations
  • We recommend multi-region deployment if serving geographically diverse customer bases
  • Our infrastructure can implement intelligent routing to the nearest Azure region if multiple regions are deployed
Failover & Redundancy
  • Multi-region Azure deployment with automatic failover capabilities is strongly encouraged
  • Our system can handle region failover transparently with automatic retry logic
  • Health check endpoints should be available per region for intelligent routing
  • We can implement circuit breaker patterns to detect and route around regional failures
Cross-Cloud Integration
  • Our AWS-based infrastructure integrates seamlessly with Azure-hosted APIs
  • No special networking requirements; standard HTTPS/TLS connectivity is sufficient
  • We can utilize Azure Front Door or Traffic Manager if you implement these for global load balancing