‫What is going on, guys, my name is Hussein, and I want to do another system design video because
‫it's been a while and I bet Twitter as a sister design and the only thing that we know today is the
‫features we're going to build.
‫We want to build ability to post a tweet, 140 characters or more.
‫I think it's now to 80 percent.
‫Sure.
‫I want the ability to follow people and timeline.
‫I haven't prepared for this video.
‫I don't know how I was going to end up.
‫And I want it to be organic because there is no perfect system design.
‫As you guys know, and it's always better when you see my way of thinking and how I develop things,
‫and instead of me giving you a preform thought right, because it's like, OK, how did you end up with
‫this right?
‫In order to do that, guys think about these features, right?
‫I want the ability to post the tweet, right?
‫So to post, first of all, I need to know who you are.
‫So there are some sort of authentication going on, right?
‫So these are called the technical requirements.
‫These are the high level functional functional, the high level features that the user requested.
‫But now as a result, you end up with with tens, if not hundreds, of technical requirements that you
‫just need to deal with and the user and customer doesn't really care about, right?
‫That's the thing thinking you have to do.
‫So that's the first thing.
‫Some authentication system.
‫No problem.
‫Post a tweet, right?
‫Well, I need to store these tweets somewhere.
‫So they must be a database.
‫I'll pick relational just because I'm old school and follow people.
‫Yeah, I need to be able to follow people.
‫And that implies that people can follow me.
‫All right.
‫So we need some sort of a the data to store that.
‫These are the people I am following, right?
‫A table was should do and timeline.
‫Right?
‫And yeah, I want to be able to read everyone my time last, actually, and this is come composed of
‫all the tweets from everybody I'm following.
‫This is the home timeline that lets us be very specific about this.
‫A home timeline.
‫And there is a specific use our timeline.
‫We can worry about that later.
‫All right.
‫So let's start with so let's let's build the overall architecture of this first right and let the higher
‫level of first level.
‫So I'm assuming there would be some sort of a database here that will be storing my tweets, my, my,
‫my profile while my users, people, I follow all that stuff, right?
‫And there must be a client.
‫They don't say which client to use or could be a mobile client could be a web client.
‫I mean, any kind of coin.
‫Right.
‫So based on that, I can pick the language of choice.
‫But since we live in a web world, I'm going to pick the beautiful protocol.
‫Right?
‫They didn't say that, right.
‫But the moment I say it, should it be, it just works with everything, right?
‫Because this is a very standard protocol.
‫So this is my client now.
‫That's my client supposed to be a phone.
‫All right.
‫You can tell I'm old school.
‫All right.
‫So this is the phone, right?
‫Or the web browser cannot connect to the database directly.
‫Right?
‫Because the database doesn't speak A2DP as long.
‫I mean, couch DB does, but a little bit.
‫Not it's not mature enough, I think, to to be exposed directly, to be honest, right?
‫So you need some sort of a third tier here, which is my beautiful server.
‫This is a debate that database is declined.
‫That's the high level architecture, right?
‫And you would think that I can build the rest API.
‫Maybe that's enough to me, right?
‫Why?
‫Why don't I pick GOPAC, for example, or PopSockets?
‫Well, there is no real time requirement.
‫Those guys don't don't want real time updates or server center events or anything like that fancy.
‫So a PSDB purist tip will do so.
‫Rest will live and prosper.
‫Yeah, the rest is not dead bodies.
‫Yeah, you can go a fancy with the graphic here, but do you really need it?
‫We'll find out.
‫We'll find out soon.
‫We'll find out.
‫We can always change.
‫And that's why we keep thinking and just thinking together.
‫And I'm just thinking with you right now, guys.
‫And so if the client want to, let's say, poster two, we assume authentication is trivial.
‫We know what we have done that many times, right?
‫So I want to post a tweet, right?
‫I'm going to do a post, right?
‫And I'm going to in the body.
‫I'm going to put the tweet frame
‫right that will go to the server, the deep web server.
‫Any language?
‫Will do.
‫Because guess what?
‫Because I'm using this TV protocol.
‫If your language knows how to deal with HDTV, if you build a server that deals with the.
‫You can do this language doesn't matter as long as we speak the HDTV protocol, both in the client and
‫server.
‫Well, good.
‫And that's the beauty of the TV, Brooke.
‫All right.
‫We'll get it.
‫We're going to talk about which kind of protocol it is.
‫There should be two or one, one or three.
‫Right?
‫So yeah, I post here.
‫So that's a web request goes to the server, to the web server, and the server now immediately turns
‫around and speaks the language.
‫Let's say Typekit boss Chris, so it needs to understand the Postgres wire protocol.
‫And now it sends an insert statement right to populate.
‫So that's the sequel.
‫It's inserts into the database.
‫And so that's sweet, right?
‫And meanwhile, the client's waiting right?
‫And so the DB, if once the DB it writes the database, we get a get back the results and the server
‫will receive that result.
‫And obviously it says hey installed successfully.
‫Now the server is as free to respond whatever it like.
‫So I say, OK, Jason, like a Jason sexists something like that, right?
‫Or failed based on the results, let's say I don't know.
‫Why would a tweet fail to post network error or something like that, right?
‫And here here is where you as a designer, a system designer, kind of flourish.
‫What's you?
‫We can just take this guys and spent two hours discussing this guy's right.
‫Forget about follow people and everything, right?
‫Just just like that.
‫What are the problems with this design?
‫And when I say problems, I'm not saying, well, not saying you cannot live with it.
‫It's just limitations, kind of.
‫So let's think about it.
‫Let's think about it.
‫So if I post here and something happened here, I don't know, failed to answer.
‫There was a problem with this, right?
‫What will happen?
‫It will fail, right?
‫We have the option as building the server to keep retrying.
‫Maybe we can build and retrace.
‫Right.
‫You can do that.
‫Hey, let's try again.
‫Maybe the arrows in the talk.
‫Maybe.
‫We can do this on other things.
‫Maybe we can say, OK, a client, a client, what you don't want to keep the client waiting while you're
‫retrying me because maybe you kept retrying too many times and the client is waiting for this time,
‫right?
‫And and and that's I think this is a feature that is very critical, right?
‫User experience, how do I feel as a client?
‫I posted this, but I'm getting an error right now.
‫You can think about it, says, OK, how about if I the moment I post, I immediately respond with the
‫user, right says All right.
‫Success, despite me, didn't write to the database.
‫But guess what?
‫And instead of writing into a database which could fail for any reason, right?
‫Network error, maybe primary key.
‫I don't think of primary care, but it could be.
‫It could be congestion database anything, right?
‫So here's where a message queue comes in handy, right?
‫Says OK.
‫Message queue is very it's almost like a database, but you just says, Hey, I'm going to push this
‫to the queue a request to post a tweet right to the message queue.
‫And that's it.
‫The moment you write to the queue, you're free to return it to the client.
‫And what's the benefits of this?
‫The benefits this is, the client immediately gives the respondent his his or her tweet has been posted.
‫Technically, it was not.
‫It is not in the database, right?
‫So there is a lag, but who's saying, what are you doing?
‫Why there is a queue here?
‫What the purpose of this?
‫The purpose of the queue is as we as we do the following rain.
‫You can have these tweets tweet one tweet or tweet three in the queue and then have another process
‫right here that picks this up and writes it to the database in the state.
‫And this is what it does.
‫The right tries for us.
‫So this what did we gain with this architecture now?
‫First of all, let's start with the cons.
‫It's more complex to implement, right?
‫Why?
‫Because you just introduced a new hop right in and use infrastructure to maintain.
‫And then the second thing is there is there is a maintenance part of it.
‫So that's that's that's hard.
‫The benefit of this is you can never fail a tweet.
‫Once the tweet reaches the server, assuming it reach the server, now you want to throw another monkey
‫wrench, guys.
‫What if this communication failed?
‫Right?
‫We'll go to this man.
‫What if this failed right at something in the client connection and didn't even post right?
‫Does the client lose the tweet?
‫We're going to talk about that.
‫Well, we'll keep to that, and I hope we don't forget.
‫OK, I'm going to add a note to you.
‫But this architecture with the message queue, you can immediately post and this is a very nice architecture
‫where it works across the globe, because if you have a single message queue that it's distributed or
‫the servers can just published, the message and the message queue depends which message you use, RAID
‫can take care of persisting to the database, and this is how why the selling point of Kafka sort of
‫servers like Kafka, right?
‫Or Rabbit MQ Kafka?
‫Right?
‫Obviously, building Twitter system design, you don't.
‫You didn't think that it will get introduced Kafka.
‫And I'm not saying we should go.
‫It's simplicity again.
‫Simplicity rules with everything is just let's I'm thinking this out loud with the you as I am.
‫I'm just drawing this and I'm thinking with you, right?
‫And you as as I'm thinking, just right in the comments.
‫I Hussein, that's B.S. Don't do this.
‫This is better or saying, don't do this, do this instead.
‫Or let's just think, right?
‫There is no perfect system design.
‫It's an art.
‫This is an art.
‫You basically stamp your own thinking in in the design you build.
‫And that's the that's the best craft that we have as engineers back and engineers, software engineers
‫in general, right?
‫It's just this is an art, and I want you to think like that, guys.
‫That's why I don't like to watch other people how they do something I never did before unless I attempted
‫first.
‫If I watched the viewers and then watch others, or this guy did it better than me, oh, this is a
‫better way on this.
‫I think the way I did it is better.
‫That's why watching it for the first time, even this video, I recommend that you do it first.
‫How do you do it?
‫There always be a pros and cons whatever I'm going to do.
‫There is also going to be pros and cons, and it depends on up to you as a system architect.
‫Which ones do you want and which one and you can live with?
‫All right.
‫So, yeah, so we can introduce this.
‫We can kill the whole part if we don't want to and keep it simple like that.
‫All right.
‫Another way, if we decided not to introduce a message queue, we can build in the idea of pooling here.
‫That's a little bit expensive, right?
‫And I wish someone does implements better implementation of connection and we talked about pulling guys.
‫Check out the video right here, right?
‫And essentially, we talked about connection pooling where we the server establishes a set of TCP connections
‫between the servers preheated.
‫These connections are TCP, a pre heated.
‫What does that mean?
‫It means that because the act of establishing this connection is expensive, so the server started starting
‫with 10 or four or five GCP connections, and now it sends the request in.
‫These DCP can actually receive a response.
‫So it's it's faster technically, right?
‫So that's I can do something like that, right?
‫Obviously, it's the worst thing is when you receive a post tweet request, you immediately go and establish
‫a TCP connection.
‫You don't want to do that, right?
‫That's just that will feel the LAG client feels the lag here.
‫And same thing with the message queue, by the way, guys, because this is a TCB connection, right?
‫If you establish a DCB connection between you and the server and the message key, but I pull these
‫things or at or or if the message queue like rabbit in queue and Kafka, I believe rabbit to give you
‫a Kafka supports something called channels.
‫I know this video turned to from the system design into and to on that back end concept, but let's
‫discuss it because this is you just watch this for fun and we're learning, right?
‫There's no perfect design.
‫We're just thinking about that stuff.
‫Yeah.
‫So as we if we have a single TCP connection with channels just like HDTV two with streams exactly the
‫same thing, right?
‫Where we have a single TCP connection and there are streams inside of it, right?
‫And I can send many requests in the same TCP connection and I and I tag them with the channel idea or
‫destiny mighty.
‫So the other guys pooling is important, right?
‫If you don't want to use cover to use this concept here for the database, and some of you might think
‫I was like, where's this caching layer that we're going to talk about?
‫Let's not introduce complicated things unless we absolutely have a problem, right?
‫As we think about it, right?
‫We're going to introduce caching, of course, if we need it right.
‫So now this is just posting, right?
‫This is just a right operation.
‫And let's discuss this part where the posting of the tweet failed right here between the connection
‫between the client and the server.
‫Let's change the color blue, the client.
‫So this has failed.
‫I want to post.
‫But the client was driving away from his home and he lost Wi-Fi connection.
‫Right?
‫Immediately lost the Wi-Fi connection and the posting of the tweet, right, the TCP connection establishment
‫was there, but that packet that contains the tweet or part of the tweet didn't get acknowledgement
‫from the server.
‫So the client says, Oh, looks like the connection is dead, right?
‫After a while, we found out that the TCP connection is dead.
‫And what do we do in this case, right?
‫We just failed.
‫Right?
‫And I just wrote this beautiful tweet that I cannot think of, and I posted it and I think the other
‫poster, but it didn't.
‫Right?
‫So the client just lost this tweet.
‫So this leads into a bad user experience.
‫And when I say user, I don't mean buttons and beautiful page.
‫No, I mean, how the user is experiencing their product and this is a bad user experience to us, right?
‫Because I clicked and I then I posted, Yeah, I got an error, but I lost my tweet, right?
‫So this is where it's a good idea to implement some sort of local database here at the client side.
‫A popular one is light.
‫Right?
‫And just stored the tweet locally.
‫Right.
‫What?
‫In parallel, because you're going to use writing on your client app, right?
‫Spin up a thread to write to the disk and another thread to send that.
‫And that's not going to take much.
‫And for much of your memory, because this is asynchronous request.
‫So you're going to send it and just wait might as well.
‫Just this is the same thing writing to disk.
‫So this way, if you write it to the desk, while just the act of posting the tweet will stored this
‫in the ciclo database.
‫So if this case failed?
‫Right?
‫Just have a process that stores it in the drafts, right?
‫That's the draft.
‫So those guys don't didn't tell us about this feature, right?
‫But might as well just do it right because that's they just expect it if I post a tweet, right?
‫You can think about all this stuff.
‫Guys, we're stuck right here now.
‫We didn't even move to the second feature, so I swear to God I can go in for two or three hours discussing
‫this step, but I'm not going to go through all that stuff, right?
‫Because this is going to take ages, but it's a good exercise.
‫So, yeah, it's a sequel is a very, very interesting concept, right?
‫We store this locally in all our guys.
‫This is a single data, a single user database, and it's designed for us.
‫Basically, it comes with almost ships with every phone, I guess.
‫And you can use it to store locally.
‫Yeah.
‫So yeah, if it failed, I can just pick up the next almost like a queue, right?
‫I pick up my next to a tweet and I try retry three try.
‫So that's a nice feature, right?
‫Or even though you don't have to add the feature to auto retry.
‫Right.
‫We don't want a feature to auto retry generally, just like save it to the draft to say, Hey, this
‫failed leather you don't know with an alert message, your user sop this failed.
‫You might want to try it again.
‫Click on that button and then the user will try again when that connection comes back.
‫All right, so that's that's a nice user experience post to it.
‫I think I'm going to leave it at that with the post tweet and stopped, too.
‫We didn't discuss the protocol between this and that.
‫Maybe he'll spend a few minutes discussing that.
‫And then just in the video right there.
‫So the protocol that we discussed, rest, we said rest is work, and I think it does for posting at
‫least right.
‫We didn't go through the rest stuff, but maybe with this will change.
‫No problem.
‫I might use the idea of scaling this thing right, scaling the posting process, right?
‫And if you think about it, you are one client and you're connected to one server and we introduce any
‫load balancers would introduce any of that stuff yet, right?
‫So if you think about it, you can introduce this is your back in server that communicate to the database.
‫All right.
‫And let's say we have one global database that might be OK.
‫You can introduce a load balancer that sits between the client and the server and and and takes and
‫takes these flood of tweets and scale them up.
‫How about we do that instead?
‫All right.
‫So in order to scale this, let's think about and I have an idea of just adding more servers, right?
‫I'm going to add the same copy of the server right here, right here and right here.
‫This is the web server, right?
‫And.
‫I'm still didn't discuss whether I'm using TV or HDTV to we're going to come to that right.
‫I don't know if I need that, but we'll see.
‫I know this is my client's right and my client will either have this idea, right?
‫We have multiple public servers, right?
‫Well, the specific domains and addresses.
‫And we can let the client be aware of these servers like Server one, Server two and Server three and
‫the server picks one of these servers, server one server to server thing.
‫I might say, who's saying, What do you what are you are doing?
‫That's not a load balancer.
‫Well, this is an idea of the client level load balance, and some people do that.
‫Netflix does that sometime to avoid another layer.
‫Right?
‫We're going to talk about both architecture and see what you like and you prefer this debate.
‫So the client here first makes it communication to this server, right to some sort of a server that
‫tells you, OK, these are the available servers, and then it starts stabilize in connection with one
‫of the servers, right?
‫This is the double TCP connection, which is basically the DTP protocol, right?
‫HDTV protocol.
‫So now establish this connection and I send my tweet and now if I have another client right here, it
‫does that it goes to this server and that a client goes to this summer.
‫It's just absolute random, right?
‫And this list can be obtained by basically literally hard coding this list into this device, right?
‫You can ask.
‫Another thing is that you can ask the server that you communicate with, Hey, give me the latest list
‫of servers and who's going to?
‫Oh, by the way, this one is now dead is still is three is available, right?
‫And this puts the load balancing at the client side.
‫There are benefits to this because with this, you don't have another layer of load balancer that you
‫have to worry about.
‫Plus, these servers are distributed and there is no other layer that communicates with the server directly.
‫But that but the disadvantage of this is obviously this awareness of the these servers to the client
‫side.
‫That's kind of bad because you cannot do through load balancing with this, you cannot do blue green
‫deployments or I guess is, OK, I want to connect to this guy.
‫But this I want this users to use this version versus this rhyme.
‫So that's one way to do it.
‫I just wanted to kind of talk about it before we jump into the other one, which is the most popular
‫one.
‫And that is the introduction of the load balancer, right?
‫And the load balancer.
‫There are many types of load balancers layer for layer seven.
‫Most of the time you're going to use a layer seven load balancer right following to post this tweet
‫right now.
‫I'm going to establish here is another disadvantage of this, but we're going to talk about it in a
‫minute minute.
‫So if I'm going to establish a connection between the client and the load balancer, that means talked
‫about encryption, right?
‫The server this load balancer need to serve me.
‫It's certificate, right?
‫Because I need to have the certificate of the load base or right here.
‫OK.
‫That's how that's how you establish deals between the client and the server.
‫In order to post that information, you need to encrypt stuff, right that we didn't talk about encryption
‫at all.
‫But that's the idea.
‫You encrypt that encryption communication between the client and the server, and then poof, you start
‫communicating.
‫And then the load balancer does that.
‫The following, right?
‫It connects with all of these servers.
‫Right.
‫And just shoves the connection.
‫And then if the client posted a tweet can either go to this server, which eventually ended that at
‫an airbase or the message queue.
‫It depends on which architecture, urban or goes to.
‫This all goes to this right?
‫So that's been going on depends on the algorithm you picked, whether this is a generic proxy or whether
‫this is traffic that will funnel the request to each of the servers.
‫Right.
‫And this is not one request, guys, right?
‫This is technically it's two.
‫It's between this and this and between this and this.
‫If it is a layer seven load bouncer.
‫And the reason is this is the final destination to the client.
‫That's it.
‫The the client connects to this.
‫This is the final destination.
‫That's why it's called also a reverse proxy, right?
‫Reverse proxy.
‫The client, this is.
‫The final destination to it and there the reverse proxy makes the request on behalf of the client,
‫so technically the server to the final destination back and server doesn't know their client, and that's
‫the definition of the reverse proxy.
‫Right.
‫So that's the layer seven proxy.
‫If this is, you need also the backend to be secure.
‫So you need this to understand how to do TLS right?
‫As a client frame, you need a good encryption.
‫Algorithms between this and this side of the good cipher suites at this one point three and above,
‫even for you, is going to use TLS 1.2.
‫Use a good ciphers and you should be safe.
‫But with this one boy three, you have fewer handshakes.
‫So that's the pre warming of this connection that we talked about that, right?
‫You still need some TCP connections on the back in here to accept establishment and unless if you don't
‫want to use pooling.
‫And I don't know which proxies support that you might want to use HDTV to at the back.
‫And let's think about that a little bit.
‫If I used to be two of the back end, then it's a beautiful one TCP connection.
‫And the more they do that, then I don't have a problem off at HDB smuggling, right?
‫Because there's no smuggling.
‫You have this idea with this where a client can smuggle connection if you are using pooling and if you
‫wanted the back end and I talk about this, which Steve is smuggling right here, check out this video,
‫right?
‫And well, to be too.
‫You have one TCP connection, you Shelvey's just like that.
‫The other thing multiple streams, multiple channels in the same connection.
‫So this more efficient.
‫So if you would, you want to do that load balancer?
‫Make sure your H2 all the way, because that's the future, right edge to here as to here.
‫This way you have one TB connection and then you shoves multiple stuff.
‫Let's say the user wants to post multiple tweets at once.
‫Right?
‫It's unlikely as a requirement.
‫So that's why I don't really it doesn't really matter to use a or not here because it's still a little
‫bit as a CPU intensive protocol, especially at this site, the front end of the load balancer.
‫So you got to be careful of that.
‫I guess it's all trade off, to be honest, right?
‫I can't believe we're just stuck right here discussing all that stuff.
‫So, yeah, there are many ways to solve a solution.
‫And guys and I don't know which one to pick a Lloyd Bentsen is definitely a popular one.
‫But guess what, guys?
‫This lot better will run out of connections really fast if you're using just x1 X2.
‫You got to get a little bit more money out of your book.
‫Is that they're saying, I don't think that's the same.
‫Yeah, you're going to get more out of your buck with your load balancer if you're using X2 because
‫it still has a fewer TCP connections.
‫If using edge one here and each one here, it should be one that is, then you can only send one request
‫per TB connection at a given time.
‫That's not true with pipeline, but pipeline have been proven to do.
‫Doesn't do, don't work with proxies as effective.
‫But yeah, we can use it.
‫But that that means a lot of TCP connection.
‫That means pooling.
‫As we discussed, pooling is good, but it's a very CPU hungry operation that means preheating connections.
‫That means more memory.
‫And this will this will definitely run out very quickly.
‫So if you can use QE2 on the back end and they should do in the front end, that will save you some
‫memory.
‫Those little bands that can only have so many TCP connection going.
‫So it's almost like a bottleneck.
‫That's why I like to flirt with the idea of having the client.
‫Does the load balancing by actually know that individual servers and just directly connect to them another
‫way, if using a layer four load balancer, then
‫it's not really one DC began.
‫Actually, if you think about it, there is a case where if you're using that, then it is a one TB
‫connection all the way, but it's very hard to deploy.
‫You get a change the gateway right here that you're ingress to point to that to that stuff, right?
‫Let's clean up this little bit.
‫All right.
‫Let's discuss layer four load balancing load right here.
‫So I am a client right here.
‫What kind of client is this?
‫The client makes it TCP connection between this, and this was designed initially to be connection.
‫But the beauty of the layer for connection is just it's stuck to one server, and any request that you
‫send always goes to the server.
‫It's not.
‫It is load balanced, but the first hop is on only load band.
‫So when you make the handshake Nissin request, the proxy will always remember it all.
‫Or this is based on your source IP source port.
‫I always get a forwarded to S1, so any request?
‫That you said always goes to the same server, always might be good or bad.
‫The beauty of this is you don't have to serve as share your keys and certificates with the load balancer
‫because the load balancer will have the keys right here now know that this back end server will have
‫the certificate and the certificate will be stored as part of the handshake, the TLS handshake just
‫with the back and yes, this one.
‫So it's almost like this acts like a man in the middle that doesn't know anything.
‫It's act like a pure proxy, transparent proxy.
‫That's another word for it.
‫Trans parent, proxy and your ISP is basically a transparent proxy because all packets go through it.
‫Right.
‫And that's that's it.
‫So this app all connections, you know, there is no connection sharing or the backend.
‫So it's almost like dedicated being angstrom.
‫Technically, it's more resource heavy and the backend, unless you're using a SH2, if you're using
‫it still, then you you're going to make fewer TCP connection from the client.
‫So that's good.
‫But yeah, especially on the web, if you here on the web and using a browser, right, the browser
‫does very freaky things with that when it comes to HDTV one and establish like six to 10 TCP connections
‫per domain.
‫And it just floods the server with a lot of connection, and we want to minimize this as much as possible.
‫So it is very good choice here.
‫I don't mention it because it's still experimental and I don't know much about it.
‫And I know it's three has the backbone to use TCP and instead of UDP.
‫So it's still still.
‫I need to read more about that, but I know UDP is being blocked on the firewalls and and a lot of stuff
‫that like them.
‫All right, guys.
‫I think we're going to stop here.
‫So we talked about just one feature and this is a 12 system design and we focused on the back and most
‫of the time.
‫Yeah, and that's what I like doing them because that's that's my my specialty.
‫I tor then go to specialty.
‫That's what I know.
‫I'm going to continue with part two where we discuss the other stuff here, where the follow to people
‫and home timeline and that might take us into another route and completely another game really might
‫change.
‫The design might.
‫That's why I'm I'm really surprised if someone does it with a system design and 20 minutes or 10 minutes,
‫you cannot unless you have sold this through for hours and hours and hours and days, right?
‫And then you compiled your perfect design into this compile 20 minutes.
‫Yeah, a little work, but I think I get confused when I watch videos like that because it's like,
‫Wow, how did you get into that decision?
‫How about this?
‫I have a lot of questions, right?
‫But you cannot you lose the history of what that was?
‫The designer did it.
‫You just you are given a design.
‫That's why I enjoy making things from scratch.
‫I enjoy the mistakes that I make because even this design decision that I make, they are not perfect
‫and we know we didn't even go through that database and how it is a scale sharding and all that stuff.
‫I don't like to do sharding from day one, to be honest, but if I anticipated a lot of load, then
‫I'm I might.
‫Who knows, right?
‫And just being pragmatic is is a good thing.
‫And there is a book called The Program a pragmatic programmer and what it means.
‫The gist of things is just be pragmatic means you have to follow the simple design and not chase shiny
‫things all the time.
‫Always think so.
‫It all it does.
‫Is this worth it?
‫Is this thing worth it?
‫Should I choose this?
‫Just because the technology is popular doesn't mean you have to use it right?
‫Use the basic stuff because the basic and simple stuff works.
‫Look at what's up are building.
‫They use the SMB protocol, I believe a custom version of it which uses SML, which is what is hated
‫these days.
‫People hate Excel flat out right because it's it is a text based protocol and it's heavy.
‫And it said we the list goes on.
‫But the app WhatsApp users and look at that billions and billions of users are using, I think, two
‫billion users now this this service has like how does it work?
‫Those guys squeeze every single performance of a sync, every single TCP connection that they have.
‫That's awesome.
‫And we want to think like that.
‫Guys be pragmatic.
‫Don't chase fancy stuff.
‫All right.
‫Understand the fundamentals because everything we discuss here are pure fundamentals.
‫I didn't throw, yeah, I did throw Kafka, but Kafka is a message.
‫Cura a message.
‫Rocker, think about it, and that's the basic fundamentals that we need to understand asynchronous
‫synchronous database, server, web server protocols.
‫That's what we need to learn.
‫OK, guys, that's it for me today.
‫Sorry for the long video.
‫I'm going to see in the next one, I'm going to see in the next one.
‫You guys stay awesome.
‫Goodbye.
‫What is going on, guys, my name is Hussein, and welcome to another system design VIDEO So this is
‫part two of.
‫I don't know how many parts what we're going to discuss, the Twitter system design, we have done part
‫one and we only discussed one feature.
‫This tells you how complex system design is right and my staff guys, if you don't know when it comes
‫to system design.
‫I like to go into a system design without without preparing anything, because that's what real life
‫is about.
‫The other videos on YouTube suffer from over preparation.
‫And here's what the problem with our preparation is, because if I.
‫Went off and spent days designing the best water design I can come up.
‫And I made a video about it.
‫You'll gain zero benefit, literally zero benefits.
‫Why?
‫Because you didn't know what I went through to actually come up with that design.
‫Even that that design might not be perfect.
‫So what I like to do if I'm going to do a system design VIDEO What I do is I start from scratch and
‫my brain does not.
‫I didn't prepare anything.
‫I literally come in blank and you see me stumble upon the problems and and go from one design to another
‫until I find what works.
‫And even though as you watch me do this and as I discussed what it's always like a discussion with you
‫guys when I do I, it will be a common discussion.
‫You see me.
‫I'll get Oh, was it?
‫Why did you do this?
‫Do this better?
‫I think this is better.
‫You will come up with even better design as you see me stumble upon this stuff.
‫Would I say that's my opinion?
‫I you.
‫You can agree or disagree as you like that, but that's what I prefer.
‫If you're new, especially to back an engineer for any system design, do it yourself.
‫Don't watch videos that have, like, laid down, Oh, this is the best way to do things.
‫And that's it.
‫No, there's no way.
‫There is no best design.
‫There is no final.
‫There's no perfect.
‫Because if that's what if there is a perfect design, we don't have jobs anymore, guys, because all
‫right, this guy has had just made a video that is a perfect system design.
‫Nope.
‫Doesn't exist.
‫It does not exist because someone will always make a better design that design for certain use cases.
‫And might it, it really depends.
‫What are you trying to do?
‫And this is unlimited, and this is where creativity comes into the picture.
‫You are an artist, guys.
‫You are an artist and and you're you're you're you're building a system.
‫It's like an architecture.
‫You're building a system of architecture, right?
‫It's tough.
‫And learn to enjoy it with that intro out of the way.
‫How about we get it started?
‫Guys and guys are going to start seeing time chapter as I try my best to to separate this into time
‫chapter.
‫Sometimes it works, sometimes it doesn't.
‫All right.
‫So in the previous video, we did the post tweet and we discussed it.
‫Database design.
‫We did.
‫We didn't know what dancing we did proxy.
‫We did message queuing.
‫We did.
‫We were thrown so many ideas.
‫Some of them work.
‫Some of them didn't.
‫Right.
‫But well, that's the part of the fun.
‫How long do you think system design takes in real world?
‫It takes us weeks.
‫If it's all months to do a good system design, right?
‫Things doesn't just magically pop up, right?
‫All right.
‫Today on discuss, follow people.
‫This Poppy, these puppy.
‫So now I'm going to start, as I always do, I always start from the bottom up.
‫That's the database, right?
‫So let's let's talk.
‫Think about this.
‫Implement implying that I follow people means that there is some sort of a profile to follow.
‫Right.
‫So I'm imagining some sort of a table here that will have certain columns, right?
‫They will love the idea.
‫We will have your name.
‫It will have what what other stuff?
‫Picture.
‫Ride, mile ride.
‫That's it.
‫This is the database design now.
‫That's what I'm thinking here.
‫And we can add more schema as we go again, and I'm going with the relational because I'm old school,
‫feel free to to do it and no sequel, there is no right or wrong way.
‫There are benefits and and advantages and disadvantages when it comes to everything, right?
‫I like to have acid transaction all the time.
‫I know Mango and other NoSQL databases supports acid, but doesn't matter.
‫No, we're just building the schema.
‫I like to have explicit schema.
‫This is just how I how I at all personally.
‫Don't let it influence you, right?
‫Anything you want.
‫This could be PostgreSQL.
‫Misquote me, MongoDB.
‫Me cockroach db.
‫Who cares?
‫So now this is my my profile table.
‫It's called profile table.
‫Proofs, file profile.
‫Right.
‫And now how do I?
‫Kind of build a structure that tells me that this this guy is following this guy as popular as some
‫ideas, I.D. number one.
‫Hussein.
‫I.D. number two.
‫And I don't know.
‫Mary.
‫OK, so I want to add a link that this person is following mainly, for example.
‫What is the first thing that comes to your mind?
‫I don't know.
‫I'm just throwing ideas.
‫While should we add another column here that says OK now?
‫Followed by.
‫That won't work immediately, because followed, this is a column and what are you going to be going
‫to do it as an integer?
‫Then what if you want to follow multiple people that breaks up real quick?
‫I.
‫You might say, as I am, I'm going to use Mongo and I'm going to add a field that is at best.
‫Be my guest.
‫You can do that, but things get really complex, real fast.
‫When you when you do that.
‫I'm not sure about the performance of having a list inside a column, I have never done that before,
‫but do you consider it?
‫Consider everything.
‫This is again, this is you're having fun, guys.
‫This is not stressful task.
‫Don't beat yourself up.
‫Even someone with twenty five years of experience make mistakes, and I work with people with 30 and
‫40 years of experience, and sometimes they come up with an idea and someone with a junior come up with
‫a better idea.
‫I see it all the time.
‫All the time and it happens.
‫So don't don't don't stress yourself up is just have fun with this camp and obviously not everything
‫that might work right.
‫Sometimes work sometimes is not right.
‫So, yeah, so what I'm going to do here instead, I'm having another table.
‫OK, this is old school stuff.
‫We have done this so many times.
‫I'm going to do call this the following table.
‫And this table will be.
‫I'm expecting the stable to grow very large.
‫Let's talk about this, so I'd.
‫Let's call this.
‫Source Oiti.
‫I don't know, destination I.D. did.
‫That means this guy is following this guy.
‫That's what it means.
‫Well, this guy is following this gal.
‫That's what I mean.
‫So if I had a record that says one two, that implies that Hussein is following Mary.
‫If you want to add another record saying to follows one.
‫Then Mary is following the same, right?
‫So that's that's the idea here.
‫And you can see that this stable is going to grow extremely, extremely large.
‫Imagine imagine this is Taylor Swift.
‫So you going to have the source I.D. there's going to be duplicated all over here.
‫And the destination, it is going to have different numbers.
‫So this tells me immediately I need a multi multi index, right, multicolored index.
‫So I need an index that that basically have both in in a B three maybe, right?
‫So that I can I can search this structure much more or form because this will grow very large easily,
‫right?
‫This is a big, huge table, but it depends, guys.
‫What are we trying to do?
‫Let's think about this, right?
‫So yeah, I have no.
‫The ability to follow people, what do I do in order to follow someone?
‫I write I start a transaction.
‫I write my own I.D. into the source ID and I write the destination of whom I want to follow and the
‫destination.
‫So just like that, the post request, if you're going to build it, application is extremely lightweight
‫because it's going to contain maybe a JSON with the source and destination.
‫It's extremely lightweight.
‫So I like I like the lightweight aspect of this.
‫Right, so it's very light what I can and quickly follow this stuff.
‫And I can ride to this side transaction, right?
‫And then in transaction and commit and immediately, I follow this stuff.
‫Now this is the first time.
‫The second question is.
‫All right.
‫The first question is.
‫Follow people, right?
‫Which we did.
‫Let's see if our I have problems, I don't know.
‫We'll go through that.
‫And that's what I like, I like to see that we're going to have a problem otherwise.
‫If I eliminated a very bad design and I give you what I think is good, then then this this misses the
‫point, right?
‫This is again, this is this is not the final design by any stretch of the imagination.
‫This is why why you, you you need to train yourself to design.
‫You don't need to train yourself to memorize things.
‫Well, not memorizing anything, guys.
‫Here, we're having fun.
‫You're going to do it to relearn how to system design.
‫You just have to do it and then scratch it and do it again.
‫Scratch and do it again.
‫I have no idea how this will end up.
‫God knows.
‫So let's go follow people.
‫Will this work?
‫I think it's OK.
‫I think it will work even if this stable is two three.
‫Four billion rows inserting is always fast.
‫I know that for a fact, right?
‫Inserting into a table is always fast and this.
‫I don't think it's going to be a busy table.
‫Let's think about it how often people are following orders.
‫It's not happening every second, right?
‫It's like, yeah, you click, I know people are reading the information far more than they're writing,
‫so I'm fine by using a B-plus tree here.
‫Yeah.
‫It's going to it might hurt my my SSD in the long run because the three need to be rebalanced as I insert
‫more stuff in it, but it's not that bad.
‫It's not like I'm logging if if this is a log that that is being executed, like, I don't know, 100
‫million, that's a law 100 million, 100000 times a second, then I'm going to be worried about writing
‫performance.
‫I'm not worried about write performance here, so I'm fine using a battery.
‫That means all.
‫This also influenced the database choice, right, because if abusing bigotry I'm using, I'm fine with
‫using post because I don't want to go with my sequel, right?
‫There is, there is method the advantage of using all these features, right?
‫My school had the ability to to swizzle different database engine.
‫The problem is complexity.
‫Because once you have different database engine between two tables, you cannot query against them as
‫a transactionally.
‫That's a problem.
‫But let's stick with this.
‫A simplified insert, I'm fine with this, so follow people as basically the ability to insert a row
‫in this table.
‫Use you what that Instagram or Twitter they do not allow.
‫They don't not allow you to do this mass following of just because, first of all, spam second is performance
‫they don't want you to talk to.
‫They don't want to write multiple rows here.
‫So if they want to make their arrests, endpoint or their API as light as possible, because if you
‫have mass following, then you have to kind of build a huge Jason object or group object with a lot
‫of rows in order to just slam them all in.
‫This is just to avoid that.
‫Don't add this feature to do a mass follower.
‫Right?
‫Just follow one by one.
‫It's painful.
‫I know Instagram.
‫They make it painful on you.
‫Right?
‫But they also know that people don't usually follow people on a daily or on on a on a second per second
‫basis.
‫So we're fine with this design.
‫Second feature.
‫Right.
‫The second feature is let's do the list for our source.
‫Because I think this will do followers right.
‫I want to know my followers or any profile followers.
‫So as an input, you have what?
‫You have an ID.
‫Right?
‫Given an IED, a profile, I want to know their followers, first of all, let's do the count.
‫How do I get that count of them?
‫And then we're going to do the actual list of followers.
‫The count is always easier than that.
‫And again, I'm not talking about cash in cash, who will make this even better.
‫But let's just think about the basics.
‫Guys don't introduce complexity unless you absolutely need it, right?
‫Try to optimize the the the raw level fundamentals and then try to build this caching layers and other
‫stuff on top.
‫Don't don't over.
‫Complicate things prematurely.
‫Right?
‫So how do I do account, I won't I give it an ID?
‫I need to know the floor for hours.
‫If I do a query where ID is equal, the source is equal to one count of the ID, the destination I.D.
‫And that will give me all the count of how many people I am following.
‫Or what?
‫How many?
‫The profile of folks.
‫So that's that's that's pretty neat.
‫So you can know how much people are following you.
‫How do I know how many people are?
‫You are following it's different, right?
‫That means this.
‫You are following this, right?
‫So if you are following this, what do you need to do is basically you query using the D I.D. If you
‫want to flip, you want to know your whole whom you are following, then you flip the equation and you
‫do.
‫There is I.D. So that's essentially two queries to know your followers or your following, right following
‫flash followers following.
‫So this table gives us both essentially, right?
‫Here's the thing.
‫We can.
‫We can play this differently.
‫Today, I'm proposing we do two queries on this table, right?
‫So a query where is it equality count or query?
‫Where did equal?
‫The I.D. count, and this gives you either one of them.
‫That's to queries a little bit your additional costs to answer two questions which are valid.
‫What if?
‫Can I answer this question with one query, if possible?
‫And then compile the results locally.
‫I'm not sure we can, but let's give it a shot if I can compute the this and the client side by and
‫the client, here I am the back and not that app or the web browser, I can query where its ID equals
‫the I.D. or did equal the I.D. and this will give me a huge set of rows back.
‫Man, that's a huge setback, right, because you're either here or here.
‫And now you can loop through the cursor results, and then if you are if you are in the side, you add
‫one, if you are in the ID, you add one to the follower.
‫Right.
‫This way, you compute the following versus the followers, right?
‫That's how you do it.
‫That's another way.
‫But that's I think that's you're essentially doing a big show of what Owen of MN.
‫Through the whole results set.
‫It's not bad, but I honestly don't know which one is faster doing to close and let the database handle
‫it or pull everything back and do it, look locally in the client side and their client sign in here.
‫I mean, the the the database client that executing the query, the benefit of this is, yeah, it might
‫take you a little bit longer.
‫But guess what?
‫You now and not just two questions, actually, and solved four questions, because now if you want
‫to, you can build a local client cached list.
‫With all the followers list, which answer this question, number three.
‫List followers, not the count, just actual list the followers.
‫Followers following.
‫That's pretty neat, right?
‫Because now the next thing we're going to do is we're going to keep a cash, maybe that's right this
‫too.
‫And since we already bothered the database, let's take that cash information stored somewhere else
‫because we already took the head.
‫Someone already asked for this information.
‫So the next thing they might have to do is actually either drill down and looking for followers, which
‫is something that I don't know about you, but I don't do this often.
‫You actually drill down on the followers list all of the following.
‫So if you want to, if that drills is is is is a frequent operation in your user experience, and that's
‫a completely different story.
‫Building user experience, I'm building a system design on the back and building an app is difficult
‫to build a user experience that how would the app look like?
‫Some someone would say, Oh, the app should, should, should account and and call to the followers
‫and the following, and also lists the followers at the same time or in this case.
‫This approach is better, right?
‫Because you're going to execute it once.
‫So you took the head of the database once and you're doing client side processing at the application
‫level and then you already have this information.
‫So now you can serve it very easily to the backend.
‫And here's the problem with this.
‫The problem with this is if you using a stateless architecture like rest, this will not work.
‫I believe.
‫This will not work.
‫Why?
‫Because the first request that goes to to to actually query the database and the second request to actually
‫pull this information from the cache mine, my hit and other service, my head in another process,
‫another host altogether so that where there is information is not available, you might say, Hussein,
‫I'm going to throw it in a centralized right server.
‫But what can you offer complicating your architecture that much?
‫Can you solve it by storing the state, making your application stateful in the server memory temporary
‫so that the client?
‫Can get this information when when they ask for it next.
‫Thus, rest will won't work for this.
‫If you want, you can either use Group C, which is a stateful protocol in this case, where you can
‫push this information and even better use rest with this thing than you think.
‫Old Volcano I just learned about Work Canel, and they're using fdb to push.
‫This is pretty neat.
‫So what are we going to know in this case?
‫I'm going to ask for the followers count.
‫This will do the query on both site, retrieve all the information the client and get the count immediately.
‫Send it back to the user because it's a stateful connection.
‫This case, right?
‫So I'm going to respond back using it to try to push immediately as I finish calculating this information.
‫I'm going to push the list of the followers and I'm going to post the list of the following to their
‫client.
‫And this is the actual end user client app.
‫Android app, iOS app, browser using TV to push.
‫That's another technology.
‫That's pretty neat.
‫Well, hard to get right, though, in my opinion, this is a little difficult to get away.
‫Make things simple.
‫Execute four queries one two one two.
‫And now go, as you might say, Oh, they're saying this is these are just ideas, right?
‫Which ends.
‫What if I want to display the name?
‫All that stuff question.
‫That's where a schema less architecture works really nice.
‫Where where you can put actually the name also here.
‫But that's a cost, because if I put the name here, I need to index it.
‫And if I indexed it, then if I don't index it, then first of all, if I put two columns here with
‫the names, which is the most information that we going to put, plus the pictures and the pictures,
‫we can solve it easily with the URL request.
‫That's that's not a big deal.
‫But if you put the name, then if you don't index this rose, which is OK, then you when you ask for
‫the name, you're going to head the actual row on disk, not the index, right?
‫Because that's how roll level access to pull the names, and that's a little bit little bit slightly
‫more expensive.
‫The second thing is, if the user changed their name, you have to write a transaction to update this,
‫which is also not so bad, right?
‫You can do this.
‫Get that.
‫The second solution is not is to also add them, but also index them.
‫That will increase your index size that will slow down your rights as well.
‫The fourth solution is look at this guy.
‫I'm just making up solutions because there are infinite number of ways to solve this problem.
‫And this is just me if I am with another team.
‫If you're if you're part of a team, that's the best thing you can do.
‫Deal with a smart team.
‫You can see the flow of idea.
‫I love working with my team.
‫I work because everyone throwing ideas is, Oh, this will not work, because there's this world because
‫of this, oh, this will work because of this.
‫I'm just alone here.
‫I'm thinking out loud.
‫Yeah.
‫So if I don't put that in the index, then all I have to do is basically, if I don't add them at all,
‫don't have the name, then I have this list and now I need to actually query the profile table and ask
‫for the name.
‫That is absolutely disastrous, in my opinion, because what are you going to do?
‫Select from profile, where name, where ID is in you to an end.
‫This list destroyed performance.
‫I don't like this one bit.
‫Yeah, I don't like it.
‫I don't like it.
‫So there is a way to actually write this list into another table and then join the profile and that
‫log table and then get their names.
‫But I don't like it, so I would prefer another method to do this stuff.
‫Fine.
‫Maybe since the name is information that we can capture this information somehow.
‫But.
‫I try to avoid as you you know it, as I try to avoid clashes as much as possible because they are hard.
‫It's hard to manage the cash.
‫So anything that is difficult and hard to maintain.
‫I try to avoid it and see if there's a simpler way to solve the problem.
‫But yeah, man, it looks like our best guess is to add that the names here, right?
‫Or even worse.
‫OK, here's what we're going to do.
‫Another way we can do it.
‫We're not going to obviously follow following the following we're not going to push.
‫Every single this is four million rows, we're not going to push four million followers to the client
‫throat.
‫That's just bad, right?
‫That's just bad idea, guys, guys.
‫And I want to just kind of fuel you to do this your own right.
‫Watch the video to get ideas, but to see the process?
‫That's it.
‫So this is an idea.
‫As we start compiling this list, which is our first results, right, first solution.
‫I will only push 10.
‫What is not that bad?
‫So I can query the profile table for for the list of 10 10 items, not that bad, so give me the names
‫and even give me the picture right?
‫And then and that's it.
‫Don't don't ask for more information than you need, right?
‫What what?
‫What does the user experience?
‫The display the name just shove the name back and then the followers list will be building OK.
‫We'll begin to build the followers that that that the Dow, the name that they are going to live, do
‫that.
‫And that's where you as you scroll down, you page the result, you page.
‫There is still the result, slowly pushing the rest of the information, right?
‫That's why the HDTV push is a little bit as good, but it has.
‫It's a double edged sword, right?
‫Because if the client cannot handle the the information coming from the server, it can crash literally
‫crash the app if it cannot handle.
‫So you have to do this in a smart way as much as possible.
‫Fourth way, guys, what what can we do else?
‫So a fourth, what is the fourth method?
‫The fourth method, guys, as the fourth feature is follow.
‫I went to high profile.
‫I want to Nicki Minaj's profile, and I want to know if I am following her.
‫Because I want to add the follow button, right?
‫Because this one is going to be follow if I'm not following her, it's going to be unfollow.
‫If I'm already following it, I wish to unfollow her.
‫That's how I do, right?
‫So how do how expensive is this query?
‫Let's take a look.
‫So if I go to Nicki Minaj's profile, I hear you.
‫I need to head this table, right?
‫And by hitting the staple, where does that's what I have, I have the ID, I how do I find out I searched
‫for her, which is something we didn't talk about search.
‫When I search on another I.D. and on clicking on the I.D. the fact of clicking the idea, I have the
‫I.D. information where you give me all the information here.
‫I give the old information back.
‫Can I return the fact that because I know my I.D. right?
‫When I made that query.
‫I to the stable.
‫Can I at the same time?
‫Ask whether.
‫I am following this or not.
‫I can can see the stable in a transaction transactions, I start begin a transaction, right?
‫And I then to the stable and then immediately also query this table where basically, how do I find
‫following her?
‫So that means that the ID is equal.
‫The Nicki Minaj is already at and my is it's OK.
‫One more.
‫OK.
‫In this case?
‫Account what I can do, ask for just the count, and that will give me the count.
‫And if it's greater than one, if it's greater than zero, that means I'm following her.
‫If as if it's exactly zero, that means I am not following her and that's what I do.
‫And now I return this boolean with it, right?
‫However, this is an extra cost query to this table, which is a huge right because this operation is
‫very common.
‫Guys viewing a profile is something you do a lot compared to viewing followers, right guys.
‫It's always like you have to be pragmatic like this, how often I do this versus how often I do this
‫operation and based on that, you assess.
‫All right.
‫So if I do this and I quit, I just added a few nanoseconds or milliseconds to that query.
‫And for a lot of people viewing multiple full files, especially in the same time, then that this adds
‫up to a lot.
‫So can I.
‫Can I do this asynchronously?
‫Because if I click on a profile as a user, I want the profile to be immediately displayed.
‫So I want just to head this table.
‫So let's say if I only had this table, that will be a quick query and I come back immediately.
‫Right?
‫Yeah, we have a huge table, but we have an index too, right?
‫But if I had two queries this and this, we just doubled, essentially doubled or even more than that
‫at cost of viewing a profile.
‫Do can you afford this?
‫Can you afford this plus these followers and following what?
‫You have so many questions.
‫So here's an idea.
‫If I view the profile, I can immediately give the result to the user so they can display it.
‫And that is following button becomes grayed out because we still don't know.
‫The client can then asynchronously ask the question separately, because this way you still saw the
‫the picture while you're you're you're blazing on.
‫The beauty of Nicki Minaj was just a profile picture.
‫Why are you clicking on enlarging the picture?
‫We have already asynchronously loaded the rest of the information.
‫You can do this at the client side.
‫Yes, additional inquiries.
‫But it's it's it's a better user experience because, hey, I got all the information and that's what
‫I noticed on Instagram.
‫I don't know if you click on a profile.
‫The rest of immigration takes a little bit time to populate this mind.
‫They, my are doing something like that.
‫One way is to do it this way, right?
‫The client ask for more.
‫Oh, give me this.
‫Give me this.
‫Give me that is that I am I following this?
‫Always.
‫What are the followers?
‫How many followers?
‫All that stuff, right?
‫So give the user that quick as quick as possible more information.
‫Quickest way to give it so they can feel something.
‫The rest of the that are less important.
‫They can.
‫They can ask for it later.
‫By asynchronously, the application level, the app or there's another way to push it using it should
‫be to push again a little bit dangerous, right?
‫Or I don't know.
‫I didn't talk about this user stateful protocol G, C, G or PC.
‫You have a full two way communication web sockets, Java C or all DCP anything you like.
‫Fine and then.
‫And then just swizzle the information back and forth, because if it's no longer a request response,
‫it's a request and could be multiple responses because it's stateful protocol.
‫I can send you multiple stuff all day long.
‫So don't worry about it.
‫So, yeah, that's definitely possible.
‫And I think, guys, I'm going to stop right here.
‫So we discuss so many other things.
‫Just one follow.
‫One feature, one feature.
‫Talk us.
‫I don't know how many minutes we've been discussing, but I'm going to see you in the next one.
‫You guys stay awesome, guys and keep designing, keep enjoying the process and going to see in the
‫next one.
‫You guys stay awesome.