Design of databases in high concurrency backends

Design of databases in high concurrency backends

Author
Alicia Nando Ruiz
Software Engineer at Tyris Software

Comparte esta página:

Done! You already have a backend created. It’s clean and shiny, it’s functional, it uses the latest technologies and meets all the requirements that were asked of you. You even have an optimized database, an API for users to obtain the information they want, and you’ve used a cache.

Well, it’s true that some of your endpoints are a little bit slower than perhaps they should be, but without too much danger. After all, users don’t care waiting 300ms rather than 500ms. And even if they had to wait a second it won’t be a problem. What’s a second in the life of a human? Nothing.

But what if one day you publish highly desired content and suddenly you find that 3,000,000 million users want it in the same 5-minute time range?

This would mean that a user will no longer have to wait a second to obtain the information, but rather that he is faced with a saturated system that makes him wait minutes or, in the worst case, never get a response. 

There are many ways to prepare a backend for high user concurrences, but in this post, we will focus on:

Play Video

This is ‘Daty’, a non-relational database.
Its work is to prepare data that it later provides the users.
But…wow! That’s so many people!
Don’t be sad Daty, the only thing you need is a little help.
Here comes ‘John Relational’, a relational database that will make your work easier.
John will prepare data so that all Daty will have to do is to attend users and take a breather.
But…how many requests! Poor Daty is overworked with so many users.
What if we ask for some more help?
Hi Peter CDN! Peter is a content distribution network.
Peter is so good at customer-facing and will help Daty with users.
Now Daty works really happy.
Just be happy. Just be as Daty.

Author
Alicia Nando Ruiz
Software Engineer at Tyris Software

Comparte esta página: