This post is the second installment in our series exploring the Oracle AI foosball demo, which was recently showcased at Oracle CloudWorld. The demo offered attendees an interactive experience, allowing them to play foosball on our table while real-time AI-generated analytics provided insights into their gameplay. For part one of this series, see Creating an AI foosball experience: Integrating OCI technologies.

The demo core was designed to be highly extensible. While the initial deployment focuses on handling data for a foosball table, it’s straightforward to integrate additional data sources. For example, expanding the system to track a model railway rather than a foosball game, with analytics tailored to each data source. Unlike foosball, where success is measured by goals scored, a model railway demo might gauge success by the volume of “cargo” transported.

Achieving flexibilty

We achieved this flexibility in two areas: Storing and defining the game data and transferring and processing the data.

Storing and defining

The system uses the Oracle Database 23ai to manage comprehensive game data, including event details, game specifications, such as event names, dates, player counts, and specifics about game tables. This setup allows for efficient tracking of both queued and active games, enabling simultaneous data processing from multiple events and game tables. The dynamic Oracle Cloud Infrastructure (OCI) Kubernetes Engine (OKE) adapts to varying workloads effectively.

We also monitor player information, with tables tailored to different data capture needs per event. For example, healthcare events might require different user data compared to less focused events. This flexibility helps ensure that we capture relevant data while addressing our privacy requirements, such as deleting user emails after the event if they’re not needed for retention.

The system also handles diverse game data, such as ball positions in a foosball demo or train sizes in a model railway game. To manage this complexity, we use a flexible, extensible format with REST architecture and JSON representation. The Oracle Database 23ai’s JSON capabilities allow us to integrate this data directly, with features like JSON duality facilitating relational data views. Future enhancements might include incorporating Oracle NoSQL, MySQL HeatWave or MongoDB API for advanced data storage solutions.

Transferring and processing

Our vision system generates over 30 data points per second, requiring efficient capture and processing, especially with multiple concurrent games and events. To avoid idle resources and the inefficiencies of constant human monitoring—particularly for a small, geographically dispersed team—we utilize OCI solutions.

Oracle’s API Gateway and load balancers dynamically adjust to manage data throughput, scaling automatically into the multi-Gbps range as needed. The authentication system uses a functions mechanism that efficiently handles requests by reusing instances, helping ensure quick adaptation to fluctuating request volumes.

Handling varying data levels is only part of the solution. We also must manage processing demand. For large events, the Oracle Autonomous Database can dynamically scale up to three times the base processor count. Additionally, OKE also supports horizontal scaling, efficiently managing multiple microservice instances and adjusting compute resources across the entire cluster.

Flexibility of processing

The core engine handles receiving input data from the vision system and distributing it to relevant recipients after applying business logic to verify data from active games. Implementing this process as horizontally scalable microservices is straightforward, with OKE efficiently managing the necessary scaling.

However, game-specific logic, such as generating summaries and videos for the foosball game, requires more processing. For example, when receiving game end messages, we trigger a language model to create a summary, pass it to video tools, and store the video URL. A dedicated data distribution microservice handles these tasks using configuration to route messages to appropriate services. This approach allows us to add microservices for specific logic without complicating the core engine. OKE simplifies deployment of these services with manifest files, and container images are version-controlled in OCIR, the Oracle Cloud Container Registry (OCIR).

Development

Being Kubernetes-based, OKE supports any language or framework within containers. For this project, we chose Java for its GraalVM runtime benefits. GraalVM’s native image processing optimizes Java code by removing unreachable methods and compiling it into a highly efficient native runtime. This trimming can result in up to 80% reduced memory usage and significantly faster startup times, reducing cloud resource costs proportionately.

To streamline development, we use libraries and frameworks to handle much of the coding. For the foosball core, we selected Micronaut for its efficient runtime and ahead-of-time compilation, which avoids Java introspection and further speeds up performance. Micronaut also includes modules that simplify development and deployment on OCI, such as managing database wallet files for secure Autonomous Database connections.

Availability and monitoring and management

Continuous monitoring of application health and load is crucial. Kubernetes, and by extension OKE, can automatically detect and restart failed microservice instances. It collaborates with microservices to check their request-handling capabilities, such as detecting deadlocks. Micronaut supports creating API endpoints for these health checks.

Monitoring goes beyond knowing if a service is running.  Understanding its performance is key. Cloud-native microservices typically log data to standard output, which Kubernetes captures. Tools like Fluentd can then upload this log data to OCI OpenSearch or Oracle Application Performance Monitoring.

Micronaut facilitates metrics collection and access through simple Java annotations, exporting metrics in Prometheus format and tracing in OpenTracing format. Tools like Prometheus and Grafana handle metrics, while Jaeger and Pipkin manage tracing. These tools can run within the OKE cluster or upload data to the Application Performance Monitoring service for a unified view of the entire application stack.

Security

As for any application or service at Oracle, we prioritize security, and this demo was no exception. We used the OCI API Gateway to manage access to the REST APIs that are exposed externally, while keeping some APIs restricted for internal use and testing. The API Gateway also integrates with OCI Functions for authentication purposes. We also enforce security through the OCI model to regulate access from microservices to the database.

 

Continue reading about the Oracle AI Foosball Frenzy demo in the part 3.

Get more information about Oracle’s: