Skip to main content
Anjelika Tan
Back to selected systems

Scale and operability

Making large community operations observable and controllable

Turned a failing large-user list into a wider operability programme across normalized state, queued imports and updates, cancellation, API Logs, background export and export history.

My role
Problem framing, requirements, QA scope, operational controls and client-use follow-through
Scope
User management, bulk operations and exports
Team
Product, engineering, QA, support and client operations teams
Delivery
QA scale validation with smaller production batch use
Evidence type
QA/test validation
Observed result
A test environment showed about 360 MB of duplicated Redux state at 200,000 records; later QA exercised 200,000 to 300,000-record scenarios.

Case Study 04

How the work unfolded

The original symptom was a slow user list. The product problem was that large reads and writes had no safe operating model for admins, support or client data jobs.

Problem

In QA/test with a 200,000-record community, the admin experience consumed heavy memory, repeated requests, became unresponsive and could spend more than 40 minutes on an export that did not complete.

Decision

Treat the problem as more than page rendering: redesign client state and move large jobs into queued, inspectable operations with explicit limits.

Observed result

QA loaded a 300,000-record list and completed a 50,000-record multi-field update in under 15 minutes; production use is proven at smaller batch sizes.

Sanitized product artifact

Bulk operation lifecycle

Delivery, evidence and limits for a sanitized large-community job.

  1. 1QueuedValidated input, run creation and cancellation before processing
  2. 2RunningBatched work, progress state and inspectable API logs
  3. 3Partial or errorRow outcomes, retry limits and duplicate-effect risk
  4. 4Cancelled or duplicateQueued cancellation, restart behaviour and idempotency follow-up

My contribution: I expanded a page-performance issue into requirements for state, queues, logs and recovery.

Observed result or limit: QA validated a 300,000-record list and a 50,000-record multi-field update under 15 minutes; production use is proven at smaller batch sizes.

Context

Client demand reached communities and migration plans in the hundreds of thousands of records. Admins still needed to search, update, import and export users without freezing the application or relying on engineering to inspect every job.

What I owned

I framed the affected workflows, created and sequenced product requirements, worked with engineering on the operational model, and used QA and later client jobs to keep failure states and unsafe assumptions visible. Engineering owned the state and queue implementations.

How the system evolved

Phase 1: The page stopped being an admin tool

Large-community testing exposed an unresponsive list, slow search, repeated API calls, missing profile and online state, incorrect counts and a synchronous export that exceeded 40 minutes.

What changed

  • About 1.4 GB browser memory after refresh in one test
  • About 2.5 GB during export
  • More than 40 minutes without a completed download
  • Repeated requests and broken state on core admin paths

What I shaped

I wrote the product problem around the admin workflows that had failed, not only a generic request to make the page faster.

Evidence and limits

Every number is labelled by where it came from. Test scale demonstrates validation; smaller production jobs demonstrate operation.

  • QA loaded a 300,000-record list and completed a 50,000-record multi-field update in under 15 minutes.
  • Production operation is proven for repeated 5,000-record batches, recurring automation and a bounded 10,000-record import test.
  • A restart edge produced duplicate effects for 60 users and triggered an idempotency investigation.
  • There is no proof of 300,000 active production users, a completed 746,000-user migration or safe rollback of in-progress work.

What this demonstrates

Performance work became product work once admins needed job state, cancellation, evidence and recovery. Scaling the interface without scaling the operating model would have moved the failure rather than solved it.