Lavu Kraken (Socket IO)
Tech Stack
Back End: Express.js, Node JS, Javascript, Socket.io, Redis, Node Cluster, WebSocket, Docker, JMeter(testing), Mocha, Chai.
My Role
This service was developed and managed by me, we had a team of 1 developer and 1 QA.
Issues Fixed
1. Apps fetching menu changes every X number of seconds
2. X number of apps needing to get updates for menu availability as the user made changes
Architecture
1- Secure Connection to Kraken
Kraken only allows secure connection so only authenticated users can connect to receive real time events.
2- Receiving/Sending Events
1. Kraken was architected to only be able to receive event from Redis, so all clients app that connect to kraken can only listen for events. This will reduce point of failures when receiving/sending events
2. Kraken has a feature that lets clients only receive events from an specific room, this reduces unnecessary traffic.
3. Kraken also is able to handle the edge cases when client lose the connection in the middle of an event and is not able to be delivered successfully, kraken save the event in Redis and as soon as the clients get connect the event are playback in the same order they were suppose to be delivered.
4. Kraken uses Node Cluster which is a feature of Node that allows you to use your processor to the max by splitting a node into a master and many workers that allows kraken to handle more connection and respond quicker. We use Redis to save the session of each of the workers in case a workers breaks is able to get back up all the sessions it had.
Testing
1. Unit testing: basic unit testing
2. Load testing:
- I created JMeter script to simulate X number of clients connecting at the same time and receiving events. This is allowed me to see what was the limit of connection per node
- Also generated big loads of data with multiple events to publish through Redis and check what was the limit on storing data in Redis and also how it delivered the events to the clients
