SyncApp Write-backs Architecture
Why This Matters
Write-backs are where integrations get complex — multiple services, async flows, NSQ logging, WebSocket routing. Understanding the write-back service's database schema, its API surface, and the V2 vs V3 migration will help you correctly implement and debug write-back features.
What You'll Learn
- The sync-app-writebacks service and its four database tables: generic_writeback_v3, source_tenant, writeback_mappings, source_tenant_preferences
- Service dependencies: NSQ Producer/Consumer, SyncApp Manager, Data Services, CDC Kafka topic
- Key APIs: Create Appointment, Get Source Tenant IDs, Set/Get Preferred source tenant, Refresh Source Tenant
- V2 flow (synchronous, standalone daemon) vs V3 flow (library-based, direct SyncApp Manager call)
- How appointment auto-confirmation write-backs use async NSQ multi-topic flows
- Prometheus metrics and Grafana dashboards for tracking write-back success/failure rates
Watch Video
Lesson Summary
The sync-app-writebacks service handles all write-back operations. Its key tables: generic_writeback_v3 (logs every attempt including outcome and error), source_tenant (maps site IDs to source tenant IDs), source_tenant_preferences (per-location preferred source tenant for forms vs online scheduling). V2 used a synchronous standalone daemon; V3 replaced it with an 'Integrations Platform' library that product teams import directly. Appointment confirmation uses asynchronous NSQ multi-topic flows for independent retry. All write-back attempts are logged to NSQ for auditing. Prometheus/Grafana dashboards track per-RPC success/failure rates.