Prática de Shadowing: Redis Deep Dive w/ a Ex-Meta Senior Manager - Aprenda a falar inglês com vídeo

So hello and welcome to the first of what we hope will be many deep dives on core technologies.

But today we're going to be talking about Redis.

I'm Stefan.

I am one of the co-founders of Hello Interview.

I've conducted north of 2,000 interviews in my career.

And our hope with these sessions is to give you some of the depth necessary to be successful in system design interviews.

System design is certainly about solving problems from end to end

but the interviewers in these sessions are going to be asking

you questions to try to test your knowledge to make sure

that you don't just have a cursory understanding of the concepts and the technologies that are involved.

And so what we're trying to do here is to give you some of

that foundation or at least give you a start to that foundation if you don't have it.

And Redis is a great starting point.

So why are we learning about Redis to begin with?

Well, Redis is an incredibly versatile technology.

You can use it in a number of different circumstances from caches, distributed locks, leaderboards.

It can be used as a replacement for Kafka in certain instances.

And so there's a lot of bang for your buck with learning about Redis

and how it can apply to various system design problems.

The second reason that we really prefer Redis in a lot of circumstances is because it's very simple to understand.

The conceptual model of Redis is actually quite simple and

that means that you can both explain your choices

but also understand their implications

if you need to dive into the details of how a

sql query planner is operating in postgres forget it you've got

to learn 30 years of history in order to get there meanwhile

if you need to know why a redis query is slow it's actually pretty straightforward for you to reason through

and so redis and particularly this session is hopefully a really good return on your time

so let's talk about redis starting with what it looks like from a end user or developer perspective.

Then we'll talk about how it actually operates underneath the covers.

And finally, we'll merge the two to tell you about how you can use it in various system design scenarios

and some of the pitfalls that you might encounter in those various problems.

So the first thing that you should know about Redis is it is a single threaded in-memory data structure server.

All of those words actually mean something.

Single-threaded is unusual to hear in distributed systems, mostly because it fails to utilize multi-core systems,

but it actually simplifies things quite a lot.

In many databases, the order of operations is hard to grok.

And in Redis, it's quite simple.

The first request that comes in is the first one that actually runs, and everybody else waits.

This has some dramatic implications for how you actually use Redis, but it's a great simplifier for how it's working under the covers.

The second thing to know about Redis is it is in memory.

That means it is lightning fast and can operate in sub-millisecond times, especially for simple operations like sets and gets.

It also has some implications for how you use it in your system.

You can't necessarily guarantee the durability of data, but it means you can use Redis in places that you might not others.

With a SQL database, you need to make sure that you batch all of your requests together, or you run risks of that N plus one problem.

With Redis, you can fire off a thousand requests, and the server will happily return its results to you.

It really changes how you think about operating with a database.

The last piece is that Redis is a data structure server.

What does that mean?

Well, the core of Redis is this kind of key value dictionary.

But Redis values don't necessarily need to be strings or numbers or binary blobs.

They can also be sorted sets or hashes or geospatial indexes or bloom filters.

The way that Redis operates is trying to mirror what you might think of from a data structures and algorithms course,

that you learn about a bunch of really primitive data structures, and Redis just gives you a way to use them in a distributed fashion,

which can be super convenient because it means you can take all of the knowledge

that you've accumulated in building up data structures and algorithms expertise and lift it into a system design context, which is quite nice.

Now, how does Redis actually operate?

It's really simple.

You can brew install Redis on your laptop and actually get a CLI that you can use.

And the wire protocol is very basic.

It accepts commands like what you see here.

So I can call set and I set it, I call get and I get it, I call anchor and it increments it atomically.

Each of these operates on a key.

Remember that the core of Redis is this dictionary of keys to these values,

and the commands are basically ways to manipulate the various data structures.

If you look in the Redis documentation, they are organized by the type of the data, so it wouldn't make sense, for instance, to call anchor on a hash,

but there's another command that will allow you to increment the values of a hash.

Now these commands can get pretty sophisticated.

So here's an example of a way to add an item to a stream.

That's not really important just yet.

The important thing is that you have a command type.

In this case, the add operates on a stream.

That's what the X prefix is.

And then there's the key.

That's where it's operating.

Now, why do the keys matter?

Well, the keys are really how Redis handles the multi-node environments.

So you can just run Redis on a single node.

It runs in a single thread and it can basically write the commands that successfully execute out to disk.

You can configure the interval.

The default, I think, is every one second, which basically means Redis can lose some data.

But in the ideal scenario, what will happen if the process fails is Redis will go down and when it comes back up, it will read from that file and recover somewhat gracefully.

In practice, this is horrible.

So for most people, what they're going to do is actually have a replica.

And the way that this works is you have some main or master,

and then you have a secondary that's reading from that append only file or basically from the log.

This works much like change data capture.

When a command runs successfully here, it gets run on the secondary.

There is some special behavior in Redis where if there's been five minutes or an hour and I haven't got an update,

then the secondary will basically fully rebuild from the contents of the master or main.

But in most instances, they're going to, and ideally, they're going to be caught up to one another.

But that's not very interesting.

That really constrains us to the throughput of this single instance.

We can, I guess, technically scale our read throughput indefinitely if we want to put a bunch of replicas.

But how do we scale out writes?

And this is where the key space starts to come into the picture.

So Redis has an internal concept they call a slot, which is basically a hash of the key.

I think it's usually a CRC modulo some number 16384 I think and that is the slot that that key occupies.

Theoretically when the cluster isn't resizing a single master

100

or main will own that slot and clients should be aware of all of the nodes in the cluster.

101

So if I have a request for foo, I'm going to take the hash of foo, the key, I'm going to look up the slot that it occupies

102

and then decide which node in the cluster I need to route my request to.

103

Each of the nodes in the cluster communicates via a gossip protocol, so they all know about the existence of each other as well as which keys they have,

104

which slots they have.

105

And if you make a request to the wrong host, it will tell you that key doesn't exist here, it's been moved.

106

But for performance sake, it's way more beneficial if the client knows exactly which host to go to.

107

And so that's why when you start up a client in Redis, you make it aware of all of the hosts that are available.

108

You theoretically aren't making requests that bounce across many different nodes.

109

And so this is where the key space becomes incredibly important.

110

The only way to shard Redis is through choosing your keys.

111

And then when you are choosing how to shard, you're functionally choosing how to spread your data across the key space.

112

So let's take a canonical example for a moment.

113

If you have a cache, one of the major difficulties that you usually have is what's called a hot key problem,

114

where many of your requests are going to the same key.

115

Well, how does this break Redis?

116

If one of your keys is located on this node, and the aggregate traffic to this node exceeds what this node can handle,

117

then it doesn't matter that these other hosts are out there.

118

The uneven distribution of traffic is going to kill you.

119

So what can you do?

120

Well, with Redis, one of the very common patterns is to simply append a random number to the key.

121

So that way you write the key to multiple hosts, and you can read it from multiple hosts.

122

So this provides a really crude way to distribute the load across the cluster.

123

But if you're thinking about how you scale Redis, you should be thinking about your key space.

124

This is really essential to how you reason about how Redis scales.

125

Okay, so let's walk through some common instances of using Redis in actual designs

126

and talk about the types of things that might come up in your deep dives and conversations with your interviewer.

127

So the first use of Redis, which is the most common, is to use it like a cache.

128

And the usage here is pretty simple, but let me just explain it quickly.

129

You have a database where you need to make heavy queries.

130

Maybe they're analytic queries, maybe this is a deep search index, whatever.

131

And you wanna be able to scale this.

132

So what do you do?

133

Well, we're going to create a Redis cache off to the side, and our service is first gonna check the cache.

134

It's gonna be very, very fast.

135

See if there's an entry in there for whatever query we're gonna make.

136

If there isn't, we're gonna go to the database, grab it, and then store the result in the cache.

137

If there is, we're just gonna go and take the result.

138

This is appropriate in basically any case where you can tolerate some staleness or inconsistency.

139

This is great when you have an eventually consistent system, and in a lot of cases, that's appropriate.

140

There are some places where this obviously doesn't matter.

141

Now, you set up a cache like this, you've really got two concerns that you need to address.

142

The first is the hot key issue, which I just talked about earlier.

143

And so we need to make sure

144

that our cache is spreading out the load amongst all of the instances as much as possible.

145

The way we do this in Redis is by assigning keys.

146

And so we might append values to our keys such

147

that we are evenly distributing the requests across all of our Redis cache.

148

The next thing that you need to be concerned with expiration

149

and a common question in interviews is what's the expiration policy

150

of your cache there's a bunch of different options here

151

and redis fundamentally supports them all the most common way to use redis is to use the expire command

152

or to basically attach arguments to your sets and gets

153

and what that does is after a certain time

154

that item won't be readable and

155

so basically you can say expire after you know 60 seconds

156

if that's your cache time to live and then you can guarantee

157

that anyone reading out of your cache won't read

158

that stale data another way to configure redis is in its least recently used setup

159

and this works a little bit differently the way

160

that the least recently used setup works inside redis is basically

161

you'll continue to be able to append keys into your cache and functionally indefinitely until you run out of memory.

162

And then at that point, Redis will start to evict those least recently used keys from your setup.

163

Works very much like memcache and in many cases the drop-in replacement, but a reasonable choice.

164

Another use of Redis, which is quite simple and quite popular, is to use it as a rate limiter.

165

The way this works is we want to guard this expensive service from getting lots of requests.

166

Maybe our downstream has decided that they can only accept five requests every 60 seconds.

167

So what we need to do is make sure that if we have multiple instances of this service, that they aren't all making in aggregate more than five requests over 60 seconds.

168

So how do we do this?

169

Well, I talked about the atomic increment command earlier on in the session, and what it does is it increments a key if it exists.

170

If it doesn't exist, it'll set it to one, and it'll return the final value.

171

Think of it like plus plus a variable if you're familiar with C++ or other languages that support that syntax.

172

The idea is if this value is over the limit, in my case five, then I don't want to make that request.

173

I need to wait.

174

On the other hand, if it's under that, that means that I've got space and I can proceed with the request.

175

And then the next thing I'm going to do

176

if I actually get an opportunity to make that request is I'm going to make sure that this key gets expired.

177

So I'm going to say that I need to expire this key after 60 seconds.

178

And what this is going to do in practice is it's

179

going to allow up to N requests to proceed through and then after however many seconds, in this case I've set it to a minute,

180

has finished, then that key gets automatically zeroed out and subsequent services can make a request again.

181

Now there is some mechanics that you'll have to insert here.

182

The service basically needs to make redundant calls after it gets rate limited

183

because it needs to check in again when the rate limit has expired.

184

And this also doesn't behave particularly well when the rate limits are under extreme stress.

185

So if I had maybe 60 requests that I need to make, it means that all of my services are going to be hitting Redis at the same time,

186

and I don't have any specific ordering that is going to be enforced.

187

So I might starve one service.

188

So there's a lot to talk about here in a system design interview between how you assert fairness of your services,

189

how you set the limits, what's most appropriate.

190

And this is the most basic implementation of a rate limiter.

191

There's a lot of other structures that you could potentially use that include windows

192

and give clients some idea about when they might be next in line, so on and so forth.

193

So design your rate limiter as you see fit, but keep in mind there's a lot of logistics that can go into this depending upon the needs of your system.

194

Sometimes something simple is great.

195

So far we've talked mostly about use cases of Redis that rely on its key value nature, maybe with some exploration mechanics.

196

But the value of Redis and its data structure server is primarily that these data structures can become increasingly powerful.

197

And I want to talk about a few instances of that.

198

The most powerful and honestly, the most complicated primitive that I think Redis offers is its stream.

199

And the idea behind A Kafka paper

200

that was written by LinkedIn many years ago that talks about the utility of distributed append only logs in system design.

201

You can imagine Redis streams as basically ordered lists of items.

202

They're given an ID, which is usually a timestamp as they're inserted.

203

Each of these items can have their own keys and values.

204

Think of them like JSON objects or hashes.

205

The nice thing about the stream is if we've got something

206

that we need to make sure all of the items of the stream are processed, then Redis gives us a bunch of primitives to work with this.

207

So let's talk about if I needed to build an async job queue.

208

So what I want to be able to do is insert items onto

209

that queue and have them processed in order and reliably.

210

I want to make sure that if an item is inserted onto the queue, that it will eventually get processed.

211

What I'm going to do for storing these items is I'm going to create a stream.

212

I'll put each of those items on the stream as they're created.

213

And then next, I'm going to create this thing called a consumer group.

214

You can think of a consumer group like a pointer into the stream.

215

And that pointer basically defines where we're at.

216

And so a consumer group will keep track of where in the stream it has to keep processing.

217

The workers can each query the consumer group for unallocated items.

218

So if the consumer group happens to be pointing at item two and no workers have picked that one up, then that item is going to be allocated to that worker.

219

There's a final notion within streams and consumer groups around what Redis calls claiming.

220

And the idea is at any given moment, only one of these workers can have claimed an item on the consumer group.

221

And if, for instance, the worker fails, which it's apt to do,

222

then that item can be reclaimed by the consumer group and allocated out to an additional worker.

223

So the idea behind a Redis stream is it gives you

224

a way to distribute work amongst many workers in a way that's fault tolerant, partially, because you have all the normal caveats about Redis.

225

And that is very, very fast.

226

And so you don't have to have a bunch of latency that you insert into the process.

227

Now, what does this mean in the system design setting?

228

Well, there are a bunch of considerations that you should figure out before you go and implement this.

229

The first is you need to be able to handle failures of Redis.

230

And there are options like using a fork of Redis, like MemoryDB, that will give you more reliability.

231

You also can build some redundancy in by having replications or additional shards, basically by additional keys.

232

You'll also want to figure out how you can keep these workers allocated the right work.

233

The typical way this is accomplished is that the worker, while it's processing an item, will continue to heartbeat back to the consumer group,

234

letting it know, hey, I'm still working on this.

235

And that way the consumer group isn't snatching back the work item before it's had a chance to finish it.

236

But there are definitely scenarios in distributed system where this doesn't work.

237

As an example, if worker two loses network connectivity to the consumer group, but maybe still has it to a database or a downstream system,

238

it might continue to process that item while the consumer group reclaims it and hands it off to another worker.

239

So the behavior here is that your consumer group is going to offer at least once guarantees, but it's not going to guarantee its process exactly once.

240

And in some cases, that may be exactly what you need.

241

Let's talk about two more data structures that are really helpful in system design contexts.

242

For this application, let's pretend we want to keep a leaderboard of the top five most liked tweets

243

that contain the word tiger.

244

If you look at our tweet search answer key, you'll see a bit about where this might come up.

245

So the sorted set commands all start with Z, and their syntax is quite simple.

246

I give a key, the ranking value, in this case the number of likes, and then some string identifier.

247

In this case, I'm going to have the tweet ID, we'll call it some ID one.

248

This first tweet, let's assume it's a tweet about Tiger Woods.

249

In the next tweet, we're going to do the same thing, but for some ID two, this might be a tweet about zoo tigers, and we're gonna add the ID one.

250

Remember, I call these sorted sets, which means for any given ID, it can only have one ranking value.

251

So if, for instance, the Tiger Woods tweet got an additional like, I would run the same command with 501 to update it.

252

Now I can run this command zrem range by rank to remove items

253

that are in a specific rank or range of ranks.

254

And in this case, what I'm doing is I'm removing all but the top five.

255

So what I effectively managed here is a heap.

256

I've got the top five most liked tweets.

257

And every time I add a new tweet, I can remove the ones that are not in there.

258

And I will only actually get an incremental example in this list

259

when one of those new tweets rises to a number of likes that is greater than my top five.

260

Now it's important to remember that these run in typical sorted list times.

261

So as an example, when I'm adding things to the list, I basically am eating a log m,

262

where m is the number of items in the list, complexity.

263

And so being able to run this command keeps my list small and manageable.

264

I wouldn't want to maintain an indefinitely growing list of the tweets that contain the word tiger,

265

because then every incremental addition needs to be inserted into that sorted list.

266

And while it's logarithmic, it still is growing as the number of examples grows.

267

Now, this sounds like a pretty good idea, but remember, I'm doing this in a single key.

268

So insofar as I need to manage the top like tweets by specific keywords,

269

I can probably distribute this across a cluster by having unique keys.

270

But if I was using this to keep track of

271

all of the tweets and try to find the most liked tweets across my entire setup, then I might have a problem because they're all going to sit on a single node.

272

If I want them to sit on multiple nodes, I'm going to need to keep multiple sorted sets and then combine them at the last minute.

273

So what I would basically do is take some hash of the tweet ID,

274

and then I would keep a sorted set of the items that have that hash.

275

And then when I wanted to query this, I would query all of those sorted sets across my cluster.

276

I would need to issue however many queries for the number of shards, maybe 16 queries.

277

In practice, this is usually not a big deal, especially because Redis happens to be so fast, but it certainly does have limitations on scaling and how you build your systems.

278

Once we have the sorted set primitive, there's a lot of things that we can build on top.

279

And Redis goes out of their way to implement what I think is one of the most useful geospatial index.

280

The use cases for this vary, but essentially, if you have a big list of items

281

that have locations and you want to be able to search them by location, this is a great way to do it.

282

And so the API looks pretty basic.

283

When I want to add an item to my geospatial index, I'm going to pass in a longitude and latitude

284

and an identifier for my item

285

and that's going to add it to the index at this key

286

when i want to search

287

that index i run the geo search command give it the

288

key i'm going to give it a an anchor point

289

and then a radius and i can optionally return the distances

290

that are associated with it and this works exactly like you'd expect

291

if i have a bike rental service and i want to find all the nearby stations

292

I add the stations to my geospatial index and query.

293

The way that this works under the covers is

294

that each of these longitudes and latitudes are geohashed to give them basically a numeric identifier.

295

That numeric identifier is the ranking in the sorted set.

296

And then Redis under the covers is calculating the bounding boxes given your radius

297

and then finding all of those entries that are basically within that range in your sorted set.

298

Redis does also, in this case, ensure that you're not returning items outside that radius, so you theoretically wouldn't see an entry with a radius of 6.

299

But the important thing here probably isn't the internals.

300

The important thing is that this API is super convenient and works in a wide variety of different situations.

301

Now from a system design perspective, this isn't without its perils.

302

There's a number of cases where you might not want to do this.

303

The first is if your items aren't changing location very often, if you're not updating your data,

304

it may actually be better to just keep a static list of longitudes and latitudes

305

in the service that's actually making these queries, and then just calculate the Haversign distance for all of them.

306

If for instance, I have 1000 stores across the globe,

307

that's actually not that much to to do some simple floating point arithmetic to go and find the closest place.

308

It's certainly faster than making a network call out to Redis.

309

The other instance where this can have some trouble is that remember that the index is on a single key, which means it's on a single node.

310

If I need to go and separate this out and I need to go and shard this, then I've got to decide on some way to do that.

311

There's a lot of natural ways to do this.

312

I can calculate the geo hash on my side.

313

I can take some of the most significant bits and use those as part of the key.

314

I can break this out by continent, where frequently I'm not going to need to query across continents, or if I'm near the border,

315

maybe I'll query two, maybe North America and South America.

316

But generally speaking, I need to be concerned with how this scales if I've got, say, billions of examples.

317

The last capability of Redis that I'm going to talk about today is PubSub.

318

And PubSub is really trying to solve for this unique instance

319

where your servers need to be able to address one another in a reasonable fashion.

320

Canonical example of this would be a chat room where user one is connected to server A,

321

maybe via a WebSocket or some persistent TLS connection, and they need to message user three, who unfortunately is connected to server C.

322

How does server A know user three is on server C?

323

There's a bunch of different potential solutions to this problem.

324

Probably the most famous is to use a consistent hash ring.

325

So that way user three is always allocated to server C and server A knows that.

326

And so can send messages directly there.

327

But there's a bunch of incremental problems that happen with these consistent hash rings.

328

Notably, it's harder to manage the balance between servers and scaling them up and down requires a bunch of very careful orchestration,

329

usually with a service, something like Zookeeper.

330

But Redis has this capability called PubSub.

331

And the idea with PubSub is that the servers can connect to Redis

332

and announce a publication that they're going to be making.

333

And then on that topic, other servers can subscribe.

334

So if, for instance, user 1 connects to server A, server A is going to tell Redis that I have user 1.

335

Any messages sent to the topic for user 1 should come back to me.

336

And server C would do the same thing.

337

Now, when server A wants to send a message to server C so that user 3 gets it,

338

What it's going to do is publish to the topic of user three.

339

Redis PubSub is at most once delivery.

340

So the idea here is that the message might get to a user and it might not,

341

which is surprisingly useful in spite of its reliability issues.

342

What it typically means from a system design perspective is if you need to guarantee that messages eventually arrive, you're going to have to try something else.

343

But Redis PubSub is going to be very, very fast.

344

It's operating on a single box, and all it's doing is bouncing these requests between different services.

345

And so it can scale quite well.

346

And what this allows us to do is if we wanted to, we could swap user one and user three, they could connect to different hosts.

347

And Redis PubSub would be the registry that knew which host each user was connected to.

348

This is something that's a little bit harder to pull off with, for instance, a consistent hash ring.

349

And it also means if server A were to go down,

350

we can migrate user 3 to server B quite quickly because server B will now register its publication to that topic.

351

And for a while, those messages will go both to server A and server B, but they'll eventually get their way to user 3.

352

Like I said, there's a bunch of considerations with this.

353

I think the WhatsApp key that we have on the site talks about some of them in depth, but be happy to answer questions in the comments if you've got them.

354

Overall, thank you so much for listening in on this deep dive on Redis.

355

Redis is useful across the board in a number of different instances from geospatial indexes, leaderboards, distributed locks.

356

And so it probably has a place in your system designs.

357

And I hope this presentation, this video has really shown you that the internals of Redis aren't that complicated, and if you understand them,

358

then you can reason through some of the issues that you might expect in production.

359

So that's a wrap on our Redis Deep Dive.

360

Would love to get any feedback that you all have in the comments, any questions or follow-ups.

361

If you'd like to read more, our Redis Deep Dive write-up is available in the description below

362

and we're looking forward to making more of these for you all if you find them interesting.

363

So let us know what you'd like to see next.

364

Thanks.

365

I'm Stefan.

366

Have a great day.

📺 Mesmo canal

Elasticsearch Deep Dive w/ a Ex-Meta Senior Manager for System Design Interviews

Business EnglishInterview EnglishUniversity Students

API Design in System Design Interviews w/ Meta Staff Engineer

Business EnglishInterview EnglishUniversity Students

Recommendation System Infra Basics 1

Business EnglishUniversity StudentsWorking Adults

Consistent Hashing: Easy Explanation for System Design Interviews

Interview EnglishUniversity StudentsWorking Adults

✨ Vídeo recomendado

231 frases

Redis Crash Course - the What, Why and How to use Redis as your primary database

Business EnglishUniversity StudentsWorking Adults

405 frases

Netflix product manager mock interview and tips (with ex-Netflix Lead PM)

Business EnglishInterview EnglishUniversity Students

137 frases

JUST $1 For Billions of Tokens?! (DeepSeek v4 Pro)

Business EnglishUniversity StudentsWorking Adults

218 frases

Next.js 16.3 got good (if you care)

Business EnglishUniversity StudentsWorking Adults

120 frases

Learn Data Modeling in 8 minutes: Dimensional Data Modeling, Data Vault, and One Big Table

Business EnglishUniversity StudentsWorking Adults

106 frases

A Career in IT

Business EnglishUniversity StudentsWorking Adults

29 frases

Amazon Athena explained in 120 seconds💡

Business EnglishUniversity StudentsWorking Adults

689 frases

Database Sharding! Designing Data-Intensive Applications chapter 6

Business EnglishUniversity StudentsWorking Adults

77 frases

The Secret Sauce Behind NoSQL: LSM Tree

Business EnglishUniversity StudentsWorking Adults

180 frases

Armchair Architects: Resiliency in the Cloud – Core Patterns

Business EnglishUniversity StudentsWorking Adults

Para quem é este vídeo?

Este vídeo é ideal para aprendizes de inglês intermediários ou avançados que querem melhorar a pronúncia em inglês e expandir o vocabulário técnico, ao mesmo tempo que aprendem sobre tecnologia. Se você busca dominar a shadowing em inglês (técnica de imitação de fala) ou quer aprender inglês com YouTube de forma prática, ele é perfeito. O diálogo é claro, com explicações detalhadas, o que facilita a imitação e a compreensão de conceitos complexos, como sistemas distribuídos.

Palavras e expressões para usar no dia a dia

Deep dive: Uma exploração aprofundada. Exemplo: "Vamos fazer um deep dive sobre Redis."
Bang for your buck: Valor por dinheiro, retorno investimento. Exemplo: "Aprender Redis dá muito bang for your buck."
Cursory understanding: Compreensão superficial. Exemplo: "Não basta ter uma cursory understanding de tecnologias."
End to end: De ponta a ponta. Exemplo: "O design de sistemas envolve resolver problemas end to end."

Como acertar o sotaque nesse vídeo

O locutor fala com um sotaque claro e ritmo moderado, ideal para shadowing. Preste atenção a: - A pronúncia de "Redis" (ré-dis, com o "e" curto, não "ree-dis"). - A entonação em frases longas, como "it is a single threaded in-memory data structure server" — a ênfase cai nas palavras-chave: single threaded, in-memory, data structure. - A conexão de palavras, como "north of 2,000" (nórf ov duzenti), que é comum em inglês falado. Praticar a imitação desses detalhes ajuda a melhorar a fluência e a naturalidade na fala. Lembre: o shadowspeaks (imitação de som) é uma ferramenta poderosa para dominar o acento!

Gramática neste vídeo

As estruturas que o falante mais usa, com as palavras exatas do vídeo:

Estrutura	No vídeo
Frases condicionais if + oração, will/would + verbo — uma condição e seu resultado	if the process fails is Redis will go · If it doesn't exist, it'll set
Present perfect have/has + particípio passado — uma ação passada que ainda importa agora	I've conducted · you've accumulated · has decided
Voz passiva be + particípio passado — o foco está no que acontece, não em quem faz	are involved · be sorted · are organized
Orações relativas who / which + oração — informação extra sobre uma pessoa ou coisa	context, which is · slot, which is · Redis, which is

O que é a Técnica de Shadowing?

Shadowing é uma técnica de aprendizado de idiomas com base científica, originalmente desenvolvida para o treinamento de intérpretes profissionais. O método é simples, mas poderoso: você ouve áudio em inglês nativo e repete imediatamente em voz alta — como uma sombra seguindo o falante com 1-2 segundos de atraso. Pesquisas mostram melhora significativa na precisão da pronúncia, entonação, ritmo, sons conectados, compreensão auditiva e fluência na fala.

Técnica de shadowing: leia o guia completo passo a passo →

Prática de Shadowing: Redis Deep Dive w/ a Ex-Meta Senior Manager - Aprenda a falar inglês com vídeo

Proximity Search & Geospatial Indexes Explained

Distributed Transactions Explained: 2 Phase Commit vs Saga Pattern

Why Shopify Moved Inventory Reservations from Redis to MySQL

Concurrency in Low-level Design Interviews w/ Staff Engineer

CAP Theorem in System Design Interviews

API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer

Message Queues in System Design Interviews w/ Meta Staff Engineer

Elasticsearch Deep Dive w/ a Ex-Meta Senior Manager for System Design Interviews

API Design in System Design Interviews w/ Meta Staff Engineer

Recommendation System Infra Basics 1

Consistent Hashing: Easy Explanation for System Design Interviews

Redis Crash Course - the What, Why and How to use Redis as your primary database

Netflix product manager mock interview and tips (with ex-Netflix Lead PM)

JUST $1 For Billions of Tokens?! (DeepSeek v4 Pro)

Next.js 16.3 got good (if you care)

Learn Data Modeling in 8 minutes: Dimensional Data Modeling, Data Vault, and One Big Table

A Career in IT

Amazon Athena explained in 120 seconds💡

Database Sharding! Designing Data-Intensive Applications chapter 6

The Secret Sauce Behind NoSQL: LSM Tree

Armchair Architects: Resiliency in the Cloud – Core Patterns

Para quem é este vídeo?

Palavras e expressões para usar no dia a dia

Como acertar o sotaque nesse vídeo

Gramática neste vídeo

O que é a Técnica de Shadowing?