Layered Architecture


By Marty Wollner





The SpikerSystems e-Gamers platform is a layered architecture for defining and deploying interactive live games like Craps and Roulette. Most of the configuration and game definitions are stored in an easy-to-configure database. And yet, our architecture provides unparalleled execution speeds, far beyond what any interactive database application can achieve. In addition, our architecture is proven, rock-solid 24 x 7 non-stop 100% up time capable.


In fact, one of the systems running our architecture has the word record for continuous up time; it is running a real-time data collection system with real-time analysis and live feedback and notifications at the Ford Motor Companyís Dearborn Engine Plant. The system has run since 1996, and still running as of today (12-July-2009).


This is accomplished by first categorizing the systemís data into 2 categories; Meta data and Real-time data. Meta data are the configuration, game, and user definitions. Real-time data in our architecture mostly consists of electronic messages passed from process to process, but also includes output system data that can be archived in the database, for example, the dealer login log and player cash-in and cash-outs receipts.


Next, we have a 3-layered approach for the Meta data:


1.   Database definitions

2.   Sequential files (we call these Flat files)

3.   In-memory definitions


System users make the database definitions using interactive forms, but they donít take effect until they get Populated into the flat files. When the system is started these files are read into the internal in-memory structures, which get used for live processing. This is known as a Cold Start.


Once running, the live system can re-load this definition into memory while it is processing real-time transactions. This unique capability is known as a Warm Start, and makes our architecture able to run non-stop.


Advantages include:


1.   All-at-once system-wide configuration changes, allowing users to make broad changes in discrete steps.


2.   Changes can be made and tested on test systems before implemented on the production systems


3.   Independence from the database, so the system can run when the database is down for maintenance or even changed, for example, from Oracle to Access.


4.   Emergency changes can be made when the database is not accessible.