Firstly, great that you are learning more about DApps, it's always great to see the community growing. However, you do have some misunderstanding about the way the DApps should be designed, so I'll try to point you in the helpful direction.
Technology Used: Ruby on Rails (Back-End), React (Front end), Solidity(Smart Contract)
As pointed in this answer:
A DApp has its backend code running on a decentralized peer-to-peer
network.
DApps by definition don't have classic backend, like the RoR would be. That means, in order for your application to be called DApp, the smart contracts should contain all your backend logic. The frontend could be any JavaScript, really, along with the web3 library that gives you the APIs to communicate with the smart contract backend.
This is a completely different paradigm, which I had problems wrapping my head around for quite some time. There are decentralized alternatives for some of the classic technologies, such as IPFS or Swarm for storage or hosting your DApp website on, "users" should be tied to blockchain addresses, you could use PouchDB, etc. The DApp should be fully open-source and autonomous.
If you wish to build the betting DApp, you really don't need to store user information in database - you can program the frontend and, for example, interact through the contract which sends the % of any bet to contract in your control and have sound business model while providing good service DApp users. But if you want each bet on blockchain, the transaction costs would sometimes prove too high. However, this doesn't mean that you can't have hybrid app - true DApps in their current state do have some limitations.
Working on Lemon Email, we had to weigh some of the benefits of the established technologies (SMTP server for example) along with the benefits of decentralized applications - so we decided to create the DApp to suit everyone. We used the Ethereum Blockchain to store metadata of our interactions, and IPFS as our storage. If you wish, you can read more about our architecture here.
Some additional reading:
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://ethereum.org/dao
https://www.packtpub.com/big-data-and-business-intelligence/mastering-blockchain
Best Answer
this is a security check. actually there is no way for you to rapidly check the balance of the user without consuming gas. so you should have a logical security check before sending or spending or exchanging tokens in the SC. just put a assert,require, revert before using the balance of the user and if it failed due to insufficient balance, then update the balance of user. and inside the DApp you can check the balance of user rapidly without consuming gas.