I'd be tempted to argue the exact opposite. With something like the lottery, you want to be pretty certain that you absolutely have a record of every single ticket purchase. If a machine should suffer a fault and lose ticket purchase information that happens to contain a future winning ticket...
Run *everything* in duplicate, triplicate or better. Use a tool like VoltDB and hardware that can handle persistance at that speed, ensure that records are kept in EPOS terminals, it's also essential that some form of non-forgeable receipt is issued as well. Because you don't want a £23 Million winning ticket to either be lost in the system, or faked. Allow for online sales and assume that people will try and hack the EPOS terminals as well, so everything wants to be mediated via some form of centrally controlled authentication. In other scenarios, you can work with eventual consistency and trust remote machines a lot more (especially if they're 100% under your control), so batching makes a lot more sense. The lottery has a number of unique characteristics, which means that it's unlikely to be a good example how how to design things for other use cases. On 6 January 2012 15:19, Kirk Pepperdine <[email protected]> wrote: > very easy.. with lottery tickets you need only record what has been > picked… those results can be aggregated locally and then aggregated in > batch. Since there is a limited number of choices, typical less than 100 > million, you can easily store all of this in memory. I'd compute an index > into a cyclic group that represents all possible lottery choices. so > recording a simple counter bump. For that you can use a concurrent counter. > You can add the index to the vendor if you need to track that.. in a > similar concurrent data structure. Again, things can be aggregated later if > need be. > > Kind regards, > Kirk > On 2012-01-06, at 4:11 PM, Rakesh wrote: > > > ok, so lets say its a lottery application. > > > > That means in the run up to the big draw on Saturday night its likely > > to get insanely busy! > > > > I can't see a way around not needing transactions but if there is a > > way, please elaborate. > > > > R > > > > On 6 January 2012 14:19, Kirk Pepperdine <[email protected]> > wrote: > >> I think all the points are good.. they just lack context.. and so not > all of > >> them are going to fit.. > >> > >> Kirk > >> > >> On 2012-01-06, at 3:18 PM, Robert Casto wrote: > >> > >> All these technology ideas are great but what is the task that all these > >> people will be doing in such a short time frame? > >> > >> Can you avoid some work during this time period? Batch it up for later, > put > >> it in a queue, or have a process come by later and do cleanup when the > >> systems are less busy. Do as little as possible while accomplishing just > >> what is needed during this time. Doing less means you can get more done > in > >> the same time period without having to add more machines or make drastic > >> changes. > >> > >> On Fri, Jan 6, 2012 at 9:10 AM, Fabrizio Giudici > >> <[email protected]> wrote: > >>> > >>> On Fri, 06 Jan 2012 15:03:59 +0100, Kirk Pepperdine > >>> <[email protected]> wrote: > >>> > >>>> All nice points. > >>>> > >>>> I would add.. avoid transactions like the plague. > >>>> Single threaded will be easier to scale out.. (think http) > >>>> +1 on keep things in memory.. in fact I've customers that no longer > put > >>>> disks in their machines.. which surprisingly increases reliability.. > (which > >>>> really shouldn't be surprising). > >>> > >>> > >>> +1 on everything, including the last point, but you can have a hard > time > >>> to persuade customers acquainted to the database for decades. It's > possible > >>> to use a hybrid approach: for instance Coherence (but AFAIK other > similar > >>> products) has got a "write behind" mode in which you basically commit > to > >>> memory, and then an async task pushes stuff to the database. I'm > trying to > >>> persuade a customer to go that way, but I still see raised eyebrows. > But > >>> perhaps we'll be able to start some serious prototyping in the next > months. > >>> > >>> > >>> -- > >>> Fabrizio Giudici - Java Architect, Project Manager > >>> Tidalwave s.a.s. - "We make Java work. Everywhere." > >>> [email protected] > >>> http://tidalwave.it - http://fabriziogiudici.it > >>> > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "The Java Posse" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group at > >>> http://groups.google.com/group/javaposse?hl=en. > >>> > >> > >> > >> > >> -- > >> Robert Casto > >> www.robertcasto.com > >> www.sellerstoolbox.com > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "The Java Posse" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/javaposse?hl=en. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "The Java Posse" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/javaposse?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > Groups "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail: [email protected] gtalk / msn : [email protected] quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <[email protected]> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
