Building a Multi-Tenant Price-Monitoring SaaS Data Layer

Client Snapshot

A B2B SaaS startup building a price-monitoring product for mid-market retailers. They owned the application and billing; they needed the data engine underneath it.

The Challenge

The founders had built a working single-tenant prototype that scraped [VERIFY: 3] sites. It broke roughly [VERIFY: weekly]. Scaling it to a paying multi-tenant product surfaced problems the prototype had never faced:

• Each tenant wanted different sites, different SKUs, different check frequencies
• Anti-bot systems began blocking as volume rose
• One tenant's heavy schedule could starve another's
• Every site layout change meant a silent data gap nobody noticed until a customer complained

Objectives

• A data layer supporting [VERIFY: 7–10] retail sources with per-tenant configuration
• Scheduled collection with per-tenant isolation and fair scheduling
• Anti-bot resilience with graceful degradation, not silent failure
• Historical price storage and change-based alerting
• Health monitoring that catches breakage before customers do

The Actowiz Approach

We separated the system into four layers: collection (per-source workers), scheduling (queue with per-tenant quotas so no tenant can starve another), storage (append-only time series, never overwriting history), and monitoring (per-source health checks with expected-yield thresholds).

That last layer is the one prototypes always omit and production always needs. If a source that normally returns 5,000 records suddenly returns 40, that's a layout change, not a market event — the system flags it and alerts rather than writing garbage into a customer's dashboard.

Anti-bot handling used a rotating session pool with per-source fingerprint profiles, and a fallback ladder: if the light method fails, escalate; if escalation fails, alert rather than retry infinitely.

Compliance Note

Public product and pricing data only. Per-source rate limits configured conservatively.