Scalability

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.

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.

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.

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 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.

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.

• 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.