Look! A LebronCoin!

I Made a Silly Thing

A while ago, my buddies and I were on the topic of Bitcoin and what made it the digital currency it is today: encryption, decentralization, anonymity, transparency…

Then we thought of what Bitcoin would be without all of that.

What is YoloCoin?

This is the anti-Bitcoin. But not like what the Sith are to the Jedi. More like Jar-Jar Binks in a Stormtrooper uniform.

So of course with an idea like this, we went off to make it. I took in my own direction. I made LebronCoin.

How does one earn a LebronCoin?

Simple. You send a tweet with the hashtag “#lebron”.

A bot will reply to your tweet and notify you that you’ve earned a #LebronCoin.

Your balance is tracked so the more tweets with “#lebron” you say, the more coins you have.

To transfer a coin, tweet “#lebron” while mentioning another user. If you have sufficient funds, you will transfer one coin to this lucky individual.

Why?

If we didn’t sound like we’ve convinced you about the next big digital currency to take the world by storm, it’s because we weren’t aiming to. We had a silly idea that the only thing crazier than the idea itself was to execute it.

But what was intended to be a manifested joke actually taught me to appreciate microarchitecture.

Microservices Architecture is the Truth

Making LebronCoin is a great “Hello-World” exercise in data-pipelining. I want to give a high-level description of the development process and how I used the microservice architecture.

Data Pipeline

A data pipeline consists of processes that takes data from the point of collection to the point of storage. Data pipelines vary in numerous ways, typically in a manner that suites the business case it serves. LebronCoin is essentially a data pipeline to count Twitter hashtags.

Simple Services

Twitter allows developers to access their data as a stream. The LebronCoin stream microservice is really simple: it continuously pulls Tweets containing the “#lebron” hashtag and sends AMQP messages whose bodies contain the said Tweets. I found that the rule stating “if you can’t explain what a class does with one sentence, it is too complex” to apply really well to microservices.

Splitting off the Twitter-stream as a microservice allowed me to easily substitute a mock Twitter stream for testing. And this is crucial for early development and not pissing off the Twitter API rate-limiting gods.

Inter-Process Communication

I chose RabbitMQ for this project because I wanted to learn it. But I want to comment on another popular method of communication between microservices: REST APIs.

The appeal of REST for microservices is that it is simple and familiar, easy-to-test, and doesn’t require a broker (like RabbitMQ). REST supports a request/response pattern.

With RabbitMQ, I used the message queue as a task queue. I hope to evolve the messages to a fan-out pattern where multiple workers work on the multiple copies of the same tweet: some may parse Tweets for transactions, others are doing streaming-data processing, etc.

DynamoDB and AWS

A traditional Relational Database is a match-made-in-heaven for this project. One column would be the name of the account holder (their Twitter handle) and the other column is their LebronCoin balance. However, like with RabbitMQ, I chose something based on my desire to learn it.

DynamoDB is a pleasure to work with. I used Twitter handles as the account names and I simply increment their balances (or decrease it, depending on the transaction). I somehow dove into the original boto packages first only to find out later that boto3 is much simpler.

The coin bot is hosted on Amazon’s EC2. After setting up the IAM role for my EC2 instances to access my DynamoDB instance, putting the coin on the cloud was simple.

The Worker

Lastly, the other microservice is “the bank worker”. This service asks as the logical bank teller: they take your Tweet, perform the corresponding bank transaction, and tweets back your receipt. Specifically, there’s only string parsing, AWS DynamoDB API calls for simple CRUD operations, and Twitter API calls to Tweet replies.

Wrap-up

I don’t believe there is anything fundamentally new with microservice architecture. It is the manifestation of modularity in the age of web scale.

I really enjoyed the interaction I get from people. Basketball and Lebron seem to be the perfect topic and audience that would tolerate something like this. I plan to expand on the project by simply adding more services that listens to the tweets coming off of the queue. Microservices really allow me to scale and pivot easily.

I leave you with a LebronCoin fan: