Getting started · LessonBy Neelima, ServiceNow Architect · Published · ServiceNow · all levels
Instance architecture
What sits behind your URL: nodes, database, load balancing, and what that means day to day.
Quick answer
What sits behind your URL: nodes, database, load balancing, and what that means day to day.
Key takeaways
- Nodes share a database but hold their own caches
- Sub production instances are smaller, so performance results differ
- Semaphores and caches are per node
- Failover is managed by ServiceNow, not by customers
The shape of an instance
An instance is a set of application nodes sharing one database, behind a load balancer. Each node runs the same code and holds its own caches and semaphore pools, which is why a problem can affect one node and not another.
Instance types
Production plus sub production instances for development, test and training. Sub production instances are refreshed from production by cloning, and they are deliberately smaller, so performance tests there are indicative rather than definitive.
What it means for admins
Architecture explains behaviour you will meet often.
- Cache flushes affect one node at a time, so changes can appear inconsistently for a moment
- A long transaction consumes a semaphore on one node, not across the estate
- Scheduled jobs run on whichever node picks them up
- High availability failover happens at the datacenter level and is handled by ServiceNow
Practice challenge
+0 XPStreak ×0
Question 1 of 2
What do application nodes share?
Frequently asked questions
Can we choose which node a job runs on?
Not normally. Jobs are picked up by an available node, which is why job design should not assume node affinity.
Why did a change take a moment to appear?
Caches are per node. A cache flush propagates, and during that moment different nodes can serve slightly different configuration.