Platform Architecture
Platform Architecture
This domain tests how Artifactory's services fit together, how HA and storage are designed, and which components are stateless or stateful.
Core rules
- Artifactory 7 runs as a set of microservices behind the Router, the entry point for UI, REST, and package-manager traffic. Core services include the Artifactory service, Frontend UI, Access for authentication and authorization, Metadata, Event, and Integration services.
- Persistent state lives in a shared database and a binary store. The database stores metadata, configuration, users, permissions, and build info; the binary store holds artifact content and checksums.
- Supported production databases are external relational databases such as PostgreSQL, Oracle, and Microsoft SQL Server; embedded Derby is for evaluation, not production.
- Binary providers include filesystem/filestore, S3, Azure Blob, and Google Cloud Storage. In HA, all nodes must use the same database and the same shared binary store.
- HA nodes are stateless application instances behind a load balancer. They share configuration and storage, so a node loss should not lose artifacts; scheduled tasks and internal jobs must be HA-aware.
Worked example
A load-balanced HA deployment has three Artifactory nodes, one PostgreSQL database, and an S3 bucket. A user uploads through node A. The binary lands in S3 and metadata is committed to PostgreSQL. A download through node B reads the same metadata and binary because both nodes point to the same stores. Adding node C requires the same join key, database, and binarystore configuration, not a copy of node A's local disk.
Traps
Treating a node's local data directory as the source of truth breaks HA; filestore must be shared or object-backed. Using Derby in HA is unsupported. Replication is not HA: it copies between repositories asynchronously and does not provide a single consistent metadata view.