Introducing Project Titan: The Scalable Foundation for AAG Platform
From the inception of the AAG Platform, we knew that we had to lay the right foundations. We needed something that is secured, extensible, and which can enable the platform to scale to support the 100m+ users we projected as a stated goal in our mission statement.
What Is Project Titan?
Project Titan is the codename for the infrastructure layer of our AAG Platform. What you have seen so far in our high-level architecture diagram is the application layer. We chose to expose the information at that level first since it’s easier to understand. Now it’s time to dig deeper regarding what will allow our platform to run.
Titan Framework
There are many tools on the market that can help build large-scale systems or applications. The number of moving parts and technologies that a company has to develop, build, manage, and make everything work together in a distributed environment can be extremely complex.
Project Titan provides one framework and platform for building and deploying our microservices. Our goal is to provide a lightweight, scalable, high performance, high availability, simple, and easy-to-learn platform. It’s not only for developing services, but also for helping to standardize how service-to-service interact with each other, and are scaled, deployed, and managed.
Microservice Architecture
We adapted the microservice architecture as the core of Project Titan not only because of its popularity, but also because it scales better for both development and performance. As a fast-growing startup, we need flexibility, faster innovation, and to be prepared for the exploration stage.
But the benefits of microservices don’t come for free as there are many more moving parts than traditional monolithic applications. Designing, deploying, and managing microservices pose a challenge. Project Titan is a framework as well as a platform. We standardize how services are built and deployed, provide a set of common supporting services, and share schema in a central repository.
Developers focus on defining service definitions — including interface, data type, data store, dependency, configuration variables, and API endpoint where security can be defined based on user roles/execution context in a standard way. DevOps deploy service instances which are the service definition + deployment variable on the service grid through an admin console.
In addition, every service will have a built-in concept of space where we can logically and physically separate the services for a different domain easily at deployment time.
Built To Scale and Perform
We think the “build first, scale later” concept is very inefficient. In most cases when there are no well-defined interfaces or APIs, it’s very common that the whole application has to be rewritten.
With Project Titan, we go one level further: We look at the typical culprits that can cause any system to not be able to scale. Imagine millions of users trying to read and write to the database or trying to invoke the same set of service endpoints. If you don’t have the right architecture, your application can slow to a crawl. So what do we do in this case?
- Stateless services for scalability and high availability. States are kept in caches, DB, or caches back by DB. That way we can easily vertically and horizontally scale up and down a service to meet the required SLA (service level agreement).
- Default DB and caching services are available. With a built-in optimistic locking mechanism, we can avoid deadlocks and make database updates without locks for scalability, while at the same time handling concurrent updates with dirty reads.
JSON is the most widely used data format today, and we treat JSON as the first-class citizen in our system. Whether doing data interchange, programming business logic, saving data in cache or database, everything is stored in JSON format. We save all the data format translation and serialization/deserialization processing power for the real work.
Routing between service calls by default are synchronous with load balancer, but it can be switched to asynchronous mode easily with minimal effort.
Designed for Customers of Any Size
When your customer may be an individual or a guild of 100k+ users, the requirements can be very different. For example, a very large guild might request for a guaranteed SLA so that they are not impacted by a sudden outburst of traffic from other guilds, while a smaller guild may prefer a more economical option.
By default, we designed the architecture with multi-tenancy in mind. This means that guilds that do not need a guaranteed SLA can share infrastructure costs. With that said, we do intend to maintain a certain level of SLA regardless of the deployment. For a larger guild, we can dedicate servers and also deploy them into specific regions as needed.
Developer-Friendly. Simple and Easy to Learn.
As part of designing the infrastructure layer, we wanted to make sure that it’s easier for our engineering team to develop new applications. We also want to make sure that we can quickly onboard new engineers by standardizing and providing reusable components. Here are some examples:
- Add native support of Typed JSON where JSON has a schema with it. We can also generate typed JSON POJO, making programming errors easily discoverable at compile time. This additionally simplifies model generation for UI frameworks such as TypeScript and ReactJS, which can save developers a significant amount of time.
- With built-in resource management for International support, localization is relatively simple to do. This is crucial since we are already in seven countries, and will quickly expand to more countries in the near future.
- Write code like regular programming. Calling another service is like modules invoking one another via language‑level method/procedure calls. It is the easiest programming model to reason about. So whether a dependency service is in process or out of process (based on messaging or RPC), it can be configured at deployment time.
- We also provide a set of common/shared services to start with so developers can avoid writing boilerplate code.
Inbound Integration-Friendly
With microservices architecture, we are able to quickly expose endpoints for external applications to integrate with. We will support primarily 2 models. First one is via API key. The second one is via OAuth 2.0. OAuth 2.0 will be used for the cases where users can grant access to their own data to external applications.
Extensible and Ecosystem-Oriented
When you think of development of an application in the blockchain space, you typically think of building an application on top of the layer 1 or layer 2 protocol. That’s an application deployment infrastructure to us, and that’s what Project Titan is meant to be.
We understand that applications we provide may not always be sufficient for our users. By opening up the platform and allowing external developers to build and deploy applications, we can essentially extend our engineering capacities significantly as the ecosystem grows.
Imagine if a user desires to have certain metrics calculated differently on our dashboard. With the approach of an open platform, there are 3 possible solutions:
- Wait for us to implement a new option
- Find a better dashboard in our app store
- Commission a developer to build a custom application for you
Owners of these custom applications will also be able to monetize their applications as users install and utilize them.
As an extra incentive to bring developers onboard to help expand our ecosystem, we plan to provide grants in the future. Stay tuned for more information.
Conclusion
At AAG Ventures, we take things very seriously when it comes to building a scalable platform. With our deep knowledge and experience in enterprise software development, we intend to create the right foundation so that we can develop applications much faster without compromising the quality, security, scalability, performance, and manageability. This is going to be one of the key differentiating factors in the long run when it comes to the ability to become the backbone of metaverses.
If you are interested in learning more or wanting to explore development on our platform, do not hesitate to reach out. We are looking forward to having you join us in the effort to expand the AAG Ventures ecosystem.
AAG Ventures IDO
After raising $12.5M in an oversubscribed Private Round led by Shima Capital, Tribe Capital, and Tess Ventures, AAG Ventures is excited to announce the launch date of AAG Token IDO.
Token Launch Auction (TLA) or IDO will begin on 12th December at NOON UTC. Follow us on Twitter for news on how to participate and up-to-date information.
Have a question about the AAG IDO? Visit the AAG Ventures Telegram community to get your answer now!
