From paper notebooks to the cloud: a platform to track ~3,500 slot machines
A casino recorded every machine collection by hand, on notebook pages: machine ID, location, who performed the collection, the amount, the date and the winnings. Consolidating that data was slow, capture errors were inevitable and there was no easy way to audit who did what. With my team, we're building a platform on Oracle Cloud that captures this information digitally and traceably.
My role
Infrastructure and systems administration. The rest of the team builds the backend and frontend.
- Provisioned the VM and network (VCN, subnets, gateways) on OCI
- Installed and upgraded the runtime: Java 21 and Tomcat 11
- Linux users and permissions; host firewall with iptables
- Database: least-privilege users, mTLS wallet and IP allowlist
- WAR deployments and failure diagnosis
What the platform captures
- Each machine's SK-ID
- Location on the floor
- Person who performed the collection
- Amount, date and winnings
Goal: real-time capture, less human error and full traceability.
Architecture
Design decisions
Deliberately simple
One VM plus a managed database, inside the Always Free Tier. The design allows for three VMs (app, workers and websocket); one runs today and the others get added as the project scales.
Production separated from development
We weighed running the DB inside the VM against Autonomous Database. We chose Autonomous for production, for managed backups and fault isolation, and an Oracle XE container bound to localhost for development, with no internet exposure.
Layered security
Public and private subnets, Security Lists with minimal ingress, a persistent host firewall, mTLS database connections with a wallet, IP-restricted access and least-privilege DB users.
Problems I solved
The app couldn't open the database wallet. The certificates were owned by a different user than the one running the service (tomcat), and Oracle misleadingly reports that permissions problem as a missing file. Fix: correct the wallet's ownership and permissions for the service user.
The WAR deployed with no visible error, but the app never responded. Two stacked incompatibilities: Spring Framework 7 requires Servlet 6.1 (Tomcat 11) while the server ran Tomcat 10.1 (Servlet 6.0), and bytecode compiled for Java 21 couldn't be read by the installed JVM 17. The clue: a real Spring startup takes ~10 s, not 2. Fix: upgrade to Tomcat 11 and Java 21.
Stack
Impact
Digital capture
Collections move off paper and into a central system.
Traceability
Every collection is tied to a machine, a location and a person.
Less human error
Real-time capture removes the step of copying notebooks into spreadsheets.
Client 100% satisfied with the work delivered so far. We're measuring before vs. after (time per collection, capture errors and consolidation time) to publish real figures.