How would you design user provisioning and de-provisioning for fifteen thousand employees?

I start by separating the three concerns, because they have different mechanisms: authentication, provisioning, and de-provisioning.

Authentication is SAML to the corporate identity provider. Provisioning and de-provisioning I put on a push mechanism — the identity provider's own Salesforce connector, or a general-purpose provisioning product, driving Salesforce's SCIM-based user provisioning. That is the part that can create a user before they first log in, update attributes when someone moves department, and deactivate a leaver on the day they leave.

I will often add just-in-time provisioning on top, so attributes and permission set assignments refresh at each login. But I am explicit that just-in-time provisioning cannot be the whole answer: it only fires when someone logs in, and it has no mechanism to deactivate anyone. An org relying on it alone accumulates active accounts for people who left, which is a finding waiting to happen.

One thing I flag on Active Directory projects: Identity Connect used to be the Salesforce-provided answer here, but Salesforce has announced its retirement and is not building a replacement, so a new design should be built on a third-party provisioning tool or the SCIM APIs.