Architecture Principles

The GoodData Platform is based on hundreds of asynchronous services that are invoked by API calls issued from resources internal or external to the platform. These services are designed to be non-blocking and to require no state information to maintain, which curtails wait time.

Key Benefit: All internal communications between services are managed through API calls. As a result, the GoodData Platform can be embedded as a set of services in other platforms. 
Services can be invoked across the platform and rely on a central brokering service called the GoodData Computing Fabric to manage their tasks. For more information, see Core Platform Services.

These sets of services share the following architectural principles.



The GoodData Platform is hosted in a multi-tenant environment, which enables superior sharing of resources across customers and is already scaled to service hundreds of thousands of customer projects. Instead of deploying a solution to an individual server, GoodData allows the sharing of hardware resources, as well as the services of the platform, and passes the cost savings to the customers.

GoodData multi-tenant architecture does not in any way compromise the security of customer data.


By design, platform components with which the user interacts are abstracted from the rest of the platform. This enables continuous iteration and improvement on the underlying execution environment without requiring changes in customer data or projects. Examples:

  • Logical data model is separated from the physical data model. So, GoodData can continue to enhance and tune the physical data model, while maintaining the interface between the logical data model and physical data model. In this manner, data modelers can continue to iterate on the relationships of the data model without worrying about rebuilding the physical data model.
  • Abstracting the database interface allows GoodData to utilize the appropriate database for the underlying function. As a result, multiple types of databases have been deployed within the platform, and as needed, they can be swapped out if superior database solutions appear.

Key Benefit: The principle of abstracting user-defined data from the execution environment of the platform enables GoodData to constantly change and improve the underlying platform services without jeopardizing the data and metadata in customer projects. Migrations and upgrades are transparent to the customer, and new releases are deployed to customers without interruption.


Individual services are stateless, which means that they do not require information about the context in which they are executed. 

As a result, a task from a single user can be routed to the least utilized instance of the service without any session or state constraints. This structure enables superior overall performance and resource allocation, and new instances of services can be initiated based on dynamic loads. 

State information is maintained in the Distributed File System service and the centralized GoodData Computing Fabric, a brokering service that manages the deployment of work tasks to each of the hundreds of services within the platform. 

Key Benefit: This centralization of service management in the GoodData Computing Fabric (GCF) ensures that no single service can be a blocker; if an individual instance is bottlenecked, the GCF can initiate another instance to balance the load, dynamically shutting down service instances if the load is scaled back.

Optimized for Business Usage

The GoodData Platform has been designed specifically for use in the business enterprise. Among other design features, the following ones support the functions of the business:

  • Application layer designed to meet the requirements of a functional area of a business and its users' reporting needs
  • Easy-to-use user interface for building reports hides complexities of relational database structures
  • Flexible data modeling enables ad-hoc dimensional analysis up and down the hierarchies of the data model
    Key Benefit: In traditional MOLAP architectures, analysis is constrained by the dimensions predefined in a data cube. If a new dimension needs to be added, the entire cube must be rebuilt, often necessitating an overnight build cycle. In contrast, GoodData utilizes ROLAP technologies that do not require cubes. Clever caching techniques are used to pre-build aspects of the data hierarchy so that all users of a project can rapidly retrieve data.
  • The principle of abstraction reduces the administrative configuration for the platform to only user account management.
  • Business users can share and collaborate on the development of new reporting objects, including metrics, reports, and dashboards. Users can create discussion threads with the user interface and share or lock objects during development phases. Reports can also be generated via scheduled email for other stakeholders.

The platform also supports HOLAP style analysis. It's possible for aggregates to be stored in a cube-like structure and transaction-level records in a relational datastore for drill-through functionality.

Project Partitioning

The base unit of the data architecture is the project, also known as a datamart. Customer projects are partitioned physically and logically.

Project Architecture

In the above diagram, you can see that the project definition encapsulates the following data objects:

  • User information - users are invited to projects and assigned roles. User accounts are stored within the domain data object and are referenced in the project.
  • Project metadata - This set of data corresponds to the metrics, reports, and dashboards that users of the project define within the GoodData Portal.
  • Project data - All data that is loaded through ETL processes into the GoodData Platform is loaded into a specified project. As needed, a process can be used to load multiple projects.
  • Cached data - As queries are made from the project in the GoodData Portal, they are broken into smaller queries, which may be stored along with their retrieved data, within the project for faster retrieval by later queries executed by other project users.

Key Benefit: Since queries and results are stored in a cache available for the entire project, all project users benefit by increased usage of the reports in the project. As usage increases, performance of individual queries increases, too.

The project wrapper isolates the data and metadata of an individual project from other projects within the domain and across customers, utilizing strong security measures.

Powered by Atlassian Confluence and Scroll Viewport.