Coming from Salesforce or Pega, you're familiar with multi-tenant architecture. In that model, multiple customers share the same application and infrastructure, with their data kept separate in a shared database. It's like living in an apartment building; everyone has their own unit, but you all share the same plumbing, foundation, and electrical systems.

ServiceNow takes a different approach. Instead of a shared apartment building, it gives each customer their own house. This is called a multi-instance architecture Each customer gets their own unique instance, which includes a dedicated application stack and database. This provides significant data isolation and allows for more flexible upgrade and maintenance schedules, since an update to one customer's instance doesn't affect anyone else.

This architectural choice is a core differentiator. While a multi-tenant model like Salesforce's is built around a shared data model and metadata-driven development, ServiceNow's multi-instance design prioritizes isolation and operational autonomy for each customer.

So what's inside one of these instances? Each ServiceNow instance runs on a standard technology stack: Linux, a Java Virtual Machine, an Apache Tomcat web server, and a MySQL database. An instance isn't just one server, though. It's a collection of application nodes working together to ensure performance and high availability.

When your browser sends a request to your ServiceNow URL (like yourcompany.service-now.com), it first hits a load balancer. The load balancer's job is simple: direct your request to the least busy application node. This distributes the workload evenly, preventing any single node from becoming a bottleneck. Each node can handle user transactions, process background jobs, and run scheduled scripts. If one node fails, the load balancer automatically reroutes traffic to the healthy nodes, providing seamless failover.

The database itself is where the magic happens. ServiceNow uses a single data model, but it's not like the single model in a multi-tenant system. Here, everything lives within one database, from user records and incident tickets to system configurations and application code. ServiceNow cleverly separates data using a system of tables. System tables, often starting with sys_, store the core metadata and platform definitions. Application tables store the data for specific applications like Incident Management (incident) or Change Management (change_request).

Because all application logic and configuration are stored as metadata in these tables, ServiceNow can perform major platform upgrades without breaking your customizations. During an upgrade, the core platform code is updated, but your custom business rules, UI policies, and data models remain untouched as data in their respective tables. This is a key advantage over systems where customizations involve changing the underlying code itself.

In the early days of ServiceNow, all customizations were created in the 'Global' scope. Think of Global as a single, wide-open workspace. Any script or business rule created here could, in principle, access or modify any other part of the system. This offered immense power and flexibility, but it also came with risks. A poorly written global script for one application could accidentally interfere with another, causing unexpected bugs that were difficult to trace.

Enter scoped applications This was a major architectural evolution. A scoped application is a private, namespaced sandbox for your app. It has its own set of tables, scripts, and API permissions. By default, a scoped app cannot interfere with other applications or the core platform. If it needs to access data or functionality from another scope (including Global), it must do so through clearly defined, secure APIs.

This boundary is crucial for enterprise deployments. It allows different teams to develop and manage their own applications on the same ServiceNow instance without stepping on each other's toes. It also makes applications more secure and easier to delegate for management, install, and upgrade.

This architectural foundation, combining isolated instances with a powerful metadata-driven platform and a robust scoping model, is what allows ServiceNow to function as a unified engine for everything from IT Service Management (ITSM) to custom business apps.

This structure is fundamentally different from what you might be used to, but it provides a powerful and resilient foundation for enterprise-level services.