Every minute, a job wakes up, checks for work, finds none, and exits. Multiply that across a production environment, and the scheduler itself can become operational noise.

The real question isn't how frequently a job should run.

It's this:
Why is the scheduler searching for work that the application already knows has arrived?

In this article, I explore an on-demand orchestration pattern implemented using SQL Server Agent. The focus is on reducing unnecessary polling by allowing the application to signal when work is actually available.

📖 Read the full article here:
https://medium.com/towards-data-engineering/rethinking-sql-server-agent-scheduling-an-on-demand-orchestration-pattern-938b9fa360f6?sharedUserId=balurathinam79

I'd be interested in hearing how others have approached similar scheduling challenges in SQL Server environments. Have you experimented with on-demand execution patterns, or do you primarily rely on scheduled polling?

Do you default to SET NOCOUNT ON in stored procedures?

What's the Big Deal with SET NOCOUNT ON? - Azure SQL Dev Corner