[Crazy Go Day] Access caching : Go-Gin + Redis
Overview
Hi there !! Recently I am preparing for the backend internship of Dcard, and this series of articles (Crazy Go Day) are some development skills I learned during this period of time :)
Last article we talk about our backend system design on kubernetes, and we are going to consider some efficiency problem in this one ~
What is redis ?
Redis is an opensource in-memory database, which is more efficient on data accessing and computing compares to other classic databases like PostgresSQL and MongoDB.
Although redis can be used as primary database nowadays (with redis modules), I use it as a cache database here just for efficiency. And since redis is just for caching here, data loss can sometimes be ignored.
Scenarios that need caching
- Many users simultaneously access the same api service in short period of time.
- Many users try to access non-existent api service.
The above scenarios are very common and basic. For instance, the second scenario will happen if your manager has a typo the service url, and he share it to his twitter account which has thousands of followers haha ;)
Thus, one of a nice solution is do some caching in our middleware, so that the mistaken request won’t access our controller services which do database querys.
Solution: Simultaneous access by many users
Steps to improve this:
- When the request first time ask for resource “A”, we will query database to find that “A” for him.
- After doing database query, we will save “A” into our cache database with expiration time limit. The reason why we need to add expiration time limit is that cache database DO NOT have huge space, and the money you should pay for memory consumption will be a disaster if you rent a cloud in-memory database.
- Assume that after few seconds there is another request ask for the resource “A”, when it arrive at our backend middleware, resource “A” will be return immediately from cache !
In other words, all the requests in this period of time that ask for resource “A” can be served faster than doing database query.
Now we have understood the concept of how I do caching here, let’s dig deeper into implementation in Go :)
First, since our url data entity has its own expiration time which will cause a contradiction against the cache expiration time, we need to do some calculation as above.
After calculation, we can put the original url content into cache with expiration time.
Now we have solved the first efficiency problem ! Moreover, the middleware implementation will be discussed after solving the second problem :)
Solution: Access non-existent url
Steps to solve it (Similar to above solution, SIMPLE )
- When user first time try to access non-existent url “B”, we will query database to check whether this url exist or not.
- After ensuring this url does not exist, we record it to our cache.
- Next time when other user try to access the same non-existent url, middleware will return “RESOURCE_NOT_EXIST” to the client side!
The logic is similar to above ! Let’s start our code :)
When we cannot find the resource in DB in our controller, we store a key-value pair like <url_id>: NOT_EXIST to redis.
So next time we will know this url does not exist. Especially, you will ask what if there is another url_id created after we record it for NOT_EXIST ?
In my backend, I use uuid to represent the id of the url entity, and it will NEVER EVER generate the same one. (Power by library haha :) )
Now, we finish all of our jobs on caching !! We can finally talk about our middleware implementation !
The middleware will check the input param url_id first, and then justify that the record of url_id stands for EXIST or NOT_EXIST !
Congrats guys !!! We have built our caching technique :)
Source code here: src ❤️
Thank you for your time reading. Any suggestions are welcomed and feel free to point me out if anything is unclear.
See u guys next time! (Happy coding~
