Skip to main content

Why You Need Cron-Based Sync

The Problem with Webhooks Alone

Webhooks are the primary sync mechanism, but they can fail: Result: 1-3% of subscription changes may not sync immediately via webhooks.

The Solution: Defense in Depth

Combined reliability: 99.9%+ sync accuracy

Architecture Overview


Rate Limit Calculation

RevenueCat API Limits

Hard Limit: 480 requests per minute (8 requests per second)

Safe Operating Parameters

Why 70% Buffer?

  1. Other API usage: Your app makes real-time API calls
  2. Webhook responses: RevenueCat may call your webhook handlers
  3. Burst protection: Avoid hitting rate limit spikes
  4. Multiple services: Other systems may use the same API key

Implementation

Core Sync Function


Cron Schedule Configuration

Node.js with node-cron

System Crontab

Vercel Cron (Next.js)

AWS Lambda with EventBridge


Database Schema

Sync Logs Table

Sync Errors Table

Sync Metrics Table


Monitoring and Alerts

Key Metrics to Track

Health Check Endpoint


Best Practices

1. Gradual Rollout

Start with a small percentage of users:

2. Avoid Peak Hours

Skip sync during high-traffic periods:

3. Circuit Breaker

Stop sync if too many errors occur:

4. Exponential Backoff for Rate Limits


Performance Optimization

Batch Database Queries

Parallel Processing (with rate limit)


Testing

Manual Test

Integration Test


Troubleshooting

High Discrepancy Rate

Symptom: > 5% of syncs show discrepancies Possible Causes:
  1. Webhooks not being processed
  2. Database write failures
  3. Race conditions in webhook handler
Solution:

Job Taking Too Long

Symptom: Sync job runs longer than 5 minutes Solution: Reduce batch size or increase frequency

API Rate Limit Errors

Symptom: Getting 429 errors from RevenueCat Solution: Increase sleep time between requests

Quick Reference

Sync Job Configuration

Alert Thresholds

Priority Queue Logic

  1. Expires within 7 days (30%) - Catch expiring subscriptions
  2. Billing issues (20%) - Resolve payment problems
  3. Recently cancelled (20%) - Detect un-cancellations
  4. Stale cache 24h+ (20%) - Refresh old data
  5. Random sample (10%) - General health check

Summary

Cron job runs every 5 minutes
Processes 1,680 users per run (respects 70% rate limit buffer)
Prioritizes critical users (expiring, billing issues, etc.)
Self-healing - catches webhook failures automatically
Rate-limited - 179ms between requests
Monitored - tracks discrepancy rates and errors
Alerting - notifies on high discrepancy/error rates
Combined with webhooks: 99.9%+ sync reliability