DIGIVISTA CRM - PERFORMANCE AND SCALE REVIEW
21 October 2026 - v54

Immediate fixes in this release
- Calendar previously loaded a generic overview of up to 2,000 leads and 2,000 tasks, then repeatedly scanned and formatted every event for each visible day. It now loads only the displayed date range, groups events once, reuses date formatting, and limits crowded-day rendering. Automatic follow-ups are shown once rather than as both task and lead.
- Calendar requests are bounded to 62 days and at most 500 task events plus 500 follow-ups. A visible notice requests a narrower view when results exceed that bound. This is an explicit safety limit, not a claim that remaining records do not exist.
- Work tracker now uses server-side search, status counts and 50-row pages rather than loading and rendering 2,000 tasks at once.
- Sales funnel totals now use scoped database stage aggregates rather than the first 2,000 loaded contacts.
- Contact search and Quick activity use a short typing delay and ignore stale responses. Quick activity uses a bounded lookup endpoint that does not calculate dashboard aggregates on each keystroke. Search remains subject to permissions.
- Dashboard duplicate summaries are reduced and the detailed funnel is expandable.

What remains before 20,000,000 records
1. Move task deadlines, ownership, status and scheduler fields from generic JSON payloads into indexed typed columns or a dedicated task table. Current date filtering on JSON is still a scale limit.
2. Continue replacing the remaining generic overview loads with separate paginated module APIs. Work tracker pagination is included in v54. Use stable cursor pagination and server-side filters.
3. Use indexed exact/prefix lookup for phone and email, plus an appropriate search index for contains-anywhere names, companies and address search. Leading-wildcard LIKE across many columns is not a 20-million-record search strategy.
4. Maintain dashboard stage/source/date summaries incrementally with reconciliation. Avoid recalculating large tenant aggregates on every typing request. Scope cached results by tenant and authorised record scope, and invalidate on ownership or role changes.
5. Run imports, validation, campaigns, reminders and AI work through persistent background workers with queues, chunking, retries, idempotency and job progress. Do not rely on an open browser.
6. Keep mail, telephony and payment webhooks durable and idempotent, with separate rate limits, provider failure handling and audit trails.
7. Use a managed database sized from measurements, connection pooling, slow-query monitoring, composite indexes chosen from EXPLAIN plans, backups and tested restoration. Add replicas or partitioning only when evidence supports them.
8. Store large attachments in private object storage with access-controlled downloads and retention policies. Avoid embedding screenshots as base64 inside growing database records.
9. Instrument p50/p95/p99 endpoint latency, database time, rows scanned, payload sizes, queue delay, browser render time and errors. Set measurable service objectives.
10. Load-test isolated representative data at 100k, 1m, 5m and 20m rows, including concurrent users and imports. Test tenant and staff isolation as well as throughput. Validate backup and recovery times.

No 20-million-record certification or load test is claimed by this release.
No business data, historical records, backups or rollback packages have been deleted. Source archive size is not the primary cause of these database and rendering costs.