I’m writing this at 4am, because apparently I can’t sleep, so bear with me. I think i’m considerably funnier than I am at the best of times – much less at 4am.
This sprint has gone really well, I’m really pleased with the progress especially after the previous few weeks.
All the changes I made to the client side architecture made a huge difference. Want to know more? then continue reading my friend! for we go on an adventure into my insanity!
Alpha Release 1.1.0
Firstly, welcome Jelle and Peter to the Alpha team! I’m going to start slowly adding more people to the test team now in the hope to maximise feedback and getting into building a process!
You can read more about what’s in this release here:
During this sprint, I’ve been working with the designer to try and get a simple design to show off emotions with just eyes. Which was a lot harder than we thought and a lot of surprising answers as well as some great feedback
Thank you everyone for your comments, they’re always appreciated! (and shared them with the designer because she’s responsible for these designs)
Hot and Cold Message storage (Chat History)
I took this in a few phases this sprint, my goal was to make it so I would store messages and then retrieve them when i reload the app.
First stage was to do it with a basic local array, simple right?
1. Server receives message and sends it to cache function
2. Cache function stores it in a local array
3. App joins room
4. Server sends contents of array!
Obviously this fundamentally works but it’s not great if the server needs restarting, you lose all your room history! So next up, I wanted to use a memory cache.
Why a memory cache instead of a database?
When you’re building something like a chat service, messages can come in at a phenomenal rate, for example when we first launched SoSa the first 24 hours we saw 1 message every second in a single room!
Now imagine 4000 rooms, all very active.
I love relational databases as much as the next person but personally, I’d rather have control how much data is inserted and retrieved – creating an insert funnel allows me to scale things at a much lower cost and in a predictable way.
If we lose a profile or a DM – that’s a big deal, but if we lose a chat message, it’s not a huge deal.
—-
So I set about implementing Redis, and then a Cache service (so I could change the type of cache I use in the future and create a local in memory fall back) as you can see the implementation isn’t much different!
But shoot, I still want other nodes to be able to access the chat history and what happens if the chat instance goes offline – I don’t want to lose my data do I?
So I implemented the concept of cold / hot storage into my ORM implementation.
What this means is that every time I send a new message, the server looks at the type of data i’m working with, if the model says it’s a “delayed” model type – it will store it in the memory cache and then after a minute, a process comes along and does all the inserts in a single blast.
Retrievals will also combine the database with the memory cache for results.
We don’t keep a huge number in the “delay” cache, but it means instead of 1000 inserts spread across 1 minute, it’s a single query done once every minute which should not only be quicker but reduce the amount of time any table locks may occur
I made a diagram to explain the process, I hope it clarifies things.
Become a patron
Squid James
Guess who’s back, Back again!
Sprint 28 – a New Hope
Sprint 2 – The ummm Foundations?
Sprint 1 – The Foundations
Precursor
