Your organization is adopting SonarQube for 200+ microservices. Walk me through the SonarQube architecture (scanner, server, database) and how you would design a highly available deployment for an enterprise with 500 developers.
Quick Answer
SonarQube consists of three layers: scanners (run in CI pipelines, analyze code), the server (web UI, compute engine for processing reports, search via Elasticsearch), and the database (PostgreSQL storing rules, metrics, issues). For HA, deploy Data Center Edition with multiple application nodes behind a load balancer, a shared database cluster, and Elasticsearch cluster.
Detailed Answer
Architecture Components
The SonarQube scanner runs in CI/CD pipelines alongside the code, performing static analysis and sending reports to the server. The server has three internal processes: the Web Server (serves the UI and API), the Compute Engine (processes analysis reports asynchronously), and the Search Server (Elasticsearch for fast issue/component lookups). The database (PostgreSQL recommended for production) stores all persistent data: projects, issues, quality profiles, metrics history, and user data.
Analysis Flow
When a developer pushes code, the CI pipeline runs sonar-scanner which reads the source code, applies quality profile rules, and sends a compressed report to the server's /api/ce/submit endpoint. The Compute Engine picks up the report from its queue, processes it (resolving issues, computing metrics, updating the database), and updates the search index. This decoupling means the scanner is fast (doesn't wait for processing), and multiple reports can be queued.
Enterprise HA Design (Data Center Edition)
Deploy multiple application nodes (each running Web + Compute Engine) behind an application load balancer. All nodes share the same PostgreSQL database (use Aurora PostgreSQL or a managed HA cluster). Elasticsearch runs as a separate cluster with 3+ nodes for resilience. Store analysis report uploads on a shared filesystem (EFS/NFS) accessible by all application nodes. Each Compute Engine processes reports independently, providing horizontal scalability for analysis throughput.
Sizing and Performance
For 500 developers / 200 repos: allocate 16GB RAM per application node (Elasticsearch is memory-hungry), use at minimum a db.r5.xlarge PostgreSQL instance, and provision fast SSD storage for Elasticsearch indices. Monitor the Compute Engine queue depth (/api/ce/activity) - if reports queue for more than 5 minutes, add application nodes. Set up separate nodes for background tasks to avoid impacting UI responsiveness.