I don't think you've done the math yet on how many possible ticket combinations there are. I have more reason than most people to spend time thinking about bingo math. Get out a piece of paper and run some calculations: enumerating the whole solution space is not feasible.
Anyhow, the real solution is easier: checking a bingo card or lottery ticket for any feature you want is, essentially, O(1). Generating a lottery ticket is O(1). Generate billions, sort into piles, choose millions from piles in proper proportions, randomize order, done.
This still won't help you if you print sufficient information on the ticket to reverse engineer whether it won or not without actually purchasing it, of course.
I'm a Brit (and not a lottery player) so not fully familiar with US state scratchcard lottery game mechanics :-) The longest odds straight lottery over here is 75m to 1 which is definitely enumerable, but if you say these cards get into the billions and would crash my server then I'll believe you! Agreed that you can still generate a controlled prize distribution with random tickets generated individually rather than pregenerating all combinations - it's a bit more fiddly but perfectly doable.
All this I agree won't help if your card design is as poor as the original article was, but to address the complaint of the poster before me it's perfectly possible to randomly generate tickets while controlling the number of winning tickets - you just have to have a screening function which prevents more than your controlled number of winners making it through.
Anyhow, the real solution is easier: checking a bingo card or lottery ticket for any feature you want is, essentially, O(1). Generating a lottery ticket is O(1). Generate billions, sort into piles, choose millions from piles in proper proportions, randomize order, done.
This still won't help you if you print sufficient information on the ticket to reverse engineer whether it won or not without actually purchasing it, of course.