Last year before I joined MarkLogic, I took it on myself to start the development of an Android-based geo-location game that we’ll call “Contagion”. I had ideas for how it would work, the game design, and all kinds of areas to expand if it were successful. There are many technical challenges to overcome with this kind of project, though. In a matter of days a successful title on Google Play can go from a few users to a few hundred thousand users. Additionally, based on user feedback I would need to modify the software frequently to add features and possibly modify game design elements. All of this added up to some traditionally nasty software requirements: a technical stack with high scalability and flexibility.
Coming from a software background in enterprise java development, my instincts were to go for a classic 3-tiered architecture. The game’s business logic would live in a DropWizard (Jetty, Jersey, Jackson for HTTP, REST, and JSON handling respectively) layer running as a standoff service from MarkLogic. Writing pages of stored-procedures to hold the game’s business logic at the database level sounded like an anti-pattern to say the least. Java was a more appropriate language, I thought, than a niche functional script like XQuery. As the scope of the project grew, however, managing the hand-off between the MarkLogic platform, the service code, and the Android client code became more and more ungainly. State management issues plagued the system, introduced latency, and brought to light serious concerns about scalability.
Once I joined MarkLogic, I discovered many use cases with full enterprise applications running directly against the MarkLogic platform. In some cases tens or hundreds of thousands of concurrent users were hitting scalable MarkLogic clusters with great performance. Complex business logic was implemented directly on the platform further challenging my previously held 3-tier or bust philosophy. I do maintain there are many cases where decoupling the database platform and the business logic provides better separation of concerns and cohesion, but in the case of Contagion I decided to go with the simpler architecture given the limited resources.
When I was using a middle-tier, I wrote dense mathematical Java code calculating great circle distance between actors in the game, calculating bearings and distances traveled. Using the geo-spatial indexes and tools available in MarkLogic, much of this code could now be shelved. Less code to maintain is a major risk reducer for the project so this was a big win.
The game’s progress continues at a measured pace as we both have full time jobs with MarkLogic and families, but it’s a fun side-activity and we are both learning the nuances of the technologies involved. “Contagion” has forced us to tackle many complex details not only at the architectural level, but also in the weeds of the MarkLogic platform itself. As the project scales up, we’ll be examining classic sizing issues like when documents are created, how frequently we are updating them, and what kind of query performance we are getting with hundreds (and hopefully tens of thousands) of concurrent requests.
In addition to using this project to learn more about our product firsthand, my hope is to further explore the ways to exploit MarkLogic to the benefit of mobile platform users. In future posts, I intend to delve into our usage of groovy/grails for package management, our extensions of the REST interface on MarkLogic 8, and how we’re exercising geospatial search.