Scalability
How IdentityIQ scales to millions of identities: horizontal task servers, partitioning and database capacity planning.
IdentityIQ scales by adding task servers, partitioning heavy tasks across them, and scaling the database. It scales out for throughput more than up.
- Add task/request servers for throughput
- Partition heavy tasks across the cluster
- Scale the database for object volume
- Plan capacity from identity and account counts
Scalability is about growing gracefully as identities, accounts, entitlements and certification volume increase. IdentityIQ is designed to scale out, by adding servers and distributing work, more than up, and the shared database must scale alongside the compute tier. Planning this from real numbers, rather than hoping, is what keeps a programme healthy as it expands from a pilot to the whole enterprise.
Scaling out the compute tier
A production IdentityIQ deployment is a cluster of application-server nodes sharing one database. Nodes can be specialised:
- UI nodes serve interactive users and APIs behind a load balancer.
- Task/request servers run background work and pick up partitioned units of a large job.
Adding task servers increases throughput for aggregation, refresh and provisioning; adding UI nodes increases interactive capacity. Because work can be partitioned across the cluster, throughput grows with the number of task servers, up to the point the shared database becomes the limit.
The database is the ceiling
Since every node shares one database, that database sets the ultimate scalability ceiling. It must be sized, indexed and, for large deployments, run on capable hardware with appropriate high-availability configuration. No amount of extra application nodes helps if the database is saturated, so capacity planning starts there.
Capacity planning from real numbers
Estimate load from the quantities that actually drive it:
- Number of identities and their average number of accounts (links).
- Number of entitlements and roles.
- Certification volume, campaigns times items, which can dwarf everything else.
- Aggregation frequency and whether delta is available for each source.
Translate these into database size, task-server count and job schedules, then load-test before go-live with representative data. Under-sized databases discovered in production are the classic, painful scaling failure.
Partitioning as the scaling mechanism
Partitioning is the concrete technique that lets a big job use the whole cluster. A partitioned refresh or aggregation is divided into many units of work spread across task servers, turning a job that would run for hours single-threaded into one that completes in a fraction of the time. Designing which jobs to partition, and sizing the cluster to match, is central to scaling.
Identity Security Cloud
SailPoint's SaaS platform removes much of this planning by managing the underlying scale itself; the customer scales Virtual Appliances for connectivity rather than a database and app-server farm. For self-managed IdentityIQ, though, scaling remains an explicit architectural responsibility.
Common pitfalls
- Scaling app nodes while ignoring the database.
- No load testing with realistic volumes before production.
- Unpartitioned heavy jobs that cannot use the cluster you paid for.