The main point of focus for building a gambling site is ensuring data/domain integrity at the database level.

You need to be able to answer questions like:

- What happens to in-flight DB transactions when they fail or the app crashes?
- Are all of your domain-atomic data updates wrapped in transactions? For example, if the server crashes right after you increment my account balance but before you decrement your house bankroll, is my balance rolled back or did you just persist a bad ledger?
- If your provably-fair mechanism depends on sequential, gapless nonces (like Just-Dice's "bet number"), can you actually guarantee a gapless sequence? For example, AUTOINCREMENT in MySQL and SERIAL In Postgres do not produce gapless sequences.
- What do you do when the values change out from under your DB transactions? If some button should only increment a value in the DB once per hour and someone double-clicks it (launches two queries in flight at once), is the value incremented twice (bad)? Is it incremented once only because the queries both incremented the initial value (bad)? Or is it only incremented once because the second query fails because of your one-increment-per-hour domain constraint (good)?

The stack you use for your application layer matters very little because what matters is your ability to sufficiently answer these types of questions.