The right tool for the job

Sometimes you need to admit when you were wrong. I thought that using a NoSQL database would be an easier option than a traditional relational database. But as I started developing for it, I ran into a couple blockers. One was the item size limit of Amazon Dynamo. This would have required a redesign to a schema similar to a relational database, and would have reduced the benefit of a NoSQL model. Second was the need for transactional integrity. I needed to make sure that if one user sends a token to another, both sides have the record of the transaction for accounting purposes. There were work-arounds that I could have built for this, but ultimately it was easier to transition back to a transactional database instead. And, really, the model makes just as much sense now as with the NoSQL model.

Each user has an Account, which contains many transactions. Each transaction contains the important information about the transaction, like date, amount, sender and receiver id, etc. Each transaction also contains the stringified message from the external payment processor, for record keeping. The NoSQL model originally included all these items in one object, but that would have grown at a rate that would have made querying too expensive. So now I can lazy-load all the transaction data, and only retrieve the latest transaction if needed.

So, the moral of the story is always evaluate your options, but don’t get too tied to one technology. Be ready to admit there’s a better way to fulfill your requirements.