Jul 28, 2009 at 3:46 AM
Edited Jul 28, 2009 at 3:52 AM
I was hoping your book would help inform a fundamental architectural decision. Perhaps it's here and I'm missing it. I'm designing a system that will monitor a real-life situation in real-time for a large
audience accessing a variety of situation statistics. An example of such an application would be a site that supports 10,000 spectators monitoring the Tour de France (you know, that little bike race that just ended in Paris) including near-live stats
on the overall race leaders, jersey leaders and specific data on 160+ other riders.
So far as I can tell, your book's discussion of traditional 3-tiered architecture casts the business layer as a pass-through to the data layer and database. However, if the state of our Tour de France system
is primarily captured in a persistent storage, it's going to get bogged down by that data access layer. Rather, say for the duration of each day's ride, it might make sense to maintain the full state of the Tour as objects in server memory. The
website presentation layer (and perhaps in the future other (e.g. mobile) clients) will thus enjoy faster response time in accessing the "current state" of the Tour without suffering database roundtrips. With this possibility in mind as well as the
Microsoft .NET suite of solutions at my disposal, I'm trying to get some high-level guidance on several questions:
- Is maintaining the state of the real-time situation (e.g., Tour de France) primarily in server memory a sane approach?
- How should the event state be implemented? Is a separate business layer required (with the concomitant inter-process protocol with a presentation layer) or are there other, lighter-weight approaches
implementable within a website application?
- What's a good persistence technique (for event state recovery, later playback and deeper analysis) that won't interfere with the live event performance? Is it reasonable, for instance, for the
data layer to instantiate a light-weight listener on the business layer's event state changes with a low priority or separate database server process to capture and persist those changes?
- Are there any tricks to failover technique so that a lost business layer state can be recovered from persistent store?
If this is all too specific for this type of book, perhaps someone can point me to an article and/or sample code that sheds light on this type of architectural quandary?
Thanks for any and all suggestions!
With further research (and the right search terms), I've come across System.Web.HttpApplicationState, offering perhaps exactly what I'm looking for. Still, if that doesn't sound right or you have any suggestions, I welcome your thoughts!
Thanks very much.