• A multi style application container supporting a variety of application scenarios: service-oriented and event-driven architectures, process-oriented applications, and batch. A cohesive programming model supporting the development paradigms offered by the containers. G supports PHP, Java, .NET, Python, Perl, C and COBOL; 
• A batch container to support batch and high-performance computing-style applications; 
• A common distributed transaction manager, leveraged by the application containers for transaction integrity; 
• A high-performance computing fabric, a communication and data-sharing infrastructure combining enterprise service bus and distributed caching mechanisms to support fast events propagation, service requests dispatching and data sharing between application components and external applications; 
• Support for elastically scalable applications, system component, deployment and execution over large clusters of Linux, Unix or Windows servers but also specialized processors in pervasive computing scenarios and cloud-based computing resources; 
• The necessary development, security, management and administration features.
• A fine-grained elasticity for the most demanding requirements (e.g., on-demand deployment/undeployment of another instance of an application, an application service or a service component). 

G Cloud TP provides the following strategies to design and implement large-scale transactional applications:

1. Parallelization. G allows transactions be executed in parallel, using different physical nodes scaling the throughput and improving overall request latency.
2. Data partitioning. G provides a "logical" database or a virtual database that can be partitioned across multiple physical nodes. In this way, transactions requiring access to data belonging to different database partitions can access, in parallel, different physical nodes.
   

   For that, G breaks up large databases into smaller ones. So the classes that belong to the large database can be reallocated in smaller databases in different physical nodes according to conditions like class name, id values, among others.

   The purpose of partitioning large databases is to divide them into separate and smaller pieces so that operations on each piece can be isolated from other operations on other pieces, thus insuring that more data can be accessed by applications more of the time. Partitions also enhance availability by being placed on various physical nodes.

   If one node fails, the remaining partitions will still be available for use.With partitioned data, parallelism will allow the same list to be broken down into pieces that can be run simultaneously on different partitions to gather the data needed for the list as a whole.With G, the large database becomes into a virtual database composed by the smaller databases.

   The virtual database can be the only database used by developers when an application is created, making transparent the internal data partitioning and avoiding write additional code for manage the internal databases. 

3. Data replication. To further improve scalability and performance, data partitions can be replicated so that multiple copies of the same set of data are available on different nodes. 
4. In memory data. In order to reduce data access latency, G allows that the most frequently accessed data be kept in memory. For that G provides distributed caching layer that provides an in-memory, distributed object store in which multiple, distributed applications can place, retrieve and exchange data objects.

   Data objects are accessed via specific APIs. The cache layer is an expandable memory footprint for reliably managing data for the application tier and it is finally possible to cost-efficiently solve the challenges created by the enormous thirst for and pushing of data that originates at the client tier.

   The cache layer is responsible for initially loading the space, synchronizing its state with external data sources, locking data objects, managing transactions and emitting event notifications.