Prática de Shadowing: System Design Interview: Design Ticketmaster w/ a Ex-Meta Staff Engineer - Aprenda a falar inglês com vídeo

Escolha um modo de prática

Cada modo abre uma sala de prática em tela cheia.

905 frases

Se as frases estiverem muito curtas ou longas, clique em Edit para ajustá-las.

Welcome, everyone.

Welcome to what is the first of hopefully many system design breakdowns.

Today we're gonna be walking through a common system design interview question that's asked at many of the top companies.

So we're gonna be designing a ticket booking service like Ticketmaster.

So this question is asked a lot at Meta in particular, especially in what they call their product design interview,

though it's also asked quite a bit in the regular system design interview

now i spent five years at meta i was an interviewer

and a staff engineer there and i'm now the co -founder of hello interview

which is a site

that helps candidates prepare for upcoming interviews largely via mocks with senior fang engineers

and managers so between asking this question at meta

and asking it in mocks via hello interview i've probably asked it probably well over 50 times

and i've seen exactly where candidates of all levels do well and where they trip up.

So today, we'll walk through this problem in the same structure as if it was a real interview, but I'll periodically be interjecting with tips,

frameworks, etc. Kind of lessons learned from those many mocks that I've done across both

Meta and Hello Interview.

Lastly, before we get started, if videos aren't your thing, I've also written up a detailed kind of breakdown of this question on hello interview

so you can head over there

and read this i'll link it below you can see there's also a number of other breakdowns of common questions

that you can check out as well so without further ado let's get into it

okay before we jump immediately into designing the system let's talk about the suggested roadmap

and this is the roadmap i suggest

that you follow for any of your system design interviews particularly those

that are designing these user -facing products like design ticket master is

so the first thing

that we're going to do is we're going to talk about the requirements

this includes the functional requirements kind of the features of the system as well as the non -functional requirements

so the qualities of the system

and then we'll outline our core entities this is like what is the data that's persisted

and exchanged throughout our system we'll go over the apis

and then we'll do a high -level design which satisfies our functional requirements

so a simple design that satisfies the main features of the system

and then we'll conclude with deep dives

and these deep dives will be a conversation with the interviewer depending on your level the interviewer might even lead

this but it's going to go deeper into satisfying those non -functional requirements mainly

so this is the plan that we're going to follow and we'll go section by section

the first thing that we'll do is we'll jump right into the requirements so

when your interview starts the first thing you're going to do is you're going to start by writing down your functional requirements.

These are the features of the system and they're usually statements like users should be able to.

So when you get here, hopefully you've had some experience with this system in the past.

Usually they choose really popular systems.

If you haven't, ask the interviewer a lot about the system.

What does it do?

What's most important functionality, what its features, how do users use it, etc. Once you have that good sense,

then start to list what are the core features?

The core meaning the ones that are most necessary to make this system work and function.

So in the case of design Ticketmaster, the very first most important one is users should be able to book tickets.

So we'll add book tickets there, the shorthand of that.

In order to book a ticket, a user needs to be able to view an event.

So you can imagine viewing an event page, seeing a seat map, choosing a seat.

We'll call this viewing an event.

So view an event, view the event details, who's performing, etc. And then you can ask yourself, well, how do they get to,

we're sort of walking backwards through the user flow.

How do they get to viewing an event in the first place?

Well, they need some discovery.

They need some search.

So users should be able to search for events.

And so in my estimation, these are the main top three functional requirements.

Users can search for an event.

They'll see a dropdown list of events.

They'll click on one of them.

This will take them to an event page.

From here, they can book a ticket to that event.

Perfect.

These are usually the functional requirements that most candidates end up landing on

and the functional requirements that I sort of like push them towards if they're asking questions or need any help.

Once you've done your functional requirements, you're going to do your non -functional requirements.

And so your non -functional requirements are the qualities of the system.

They're not features, but they're the qualities of the system like scalability,

availability, reliability, fault tolerance, all these things that I'm sure you've read a number of times in the books and the resources.

The biggest mistake that candidates make here though is that they just write those terms.

They just write availability and scalability and whatever it may be, all of these illities.

This is not always strictly wrong, but it's defeating the purpose.

Like all systems have those qualities.

The important part of non -functional requirements is to identify what makes this system unique, interesting, and challenging.

And so you should

go through those illities in the context specifically of this problem

and we can do that here now

so the first question

i usually ask myself is cap theorem in the context of cap theorem is my system going to prioritize availability

or is it going to prioritize consistency

and kind of the easy right answer here particularly for a mid -level candidate is

that we're going to prioritize consistency more than availability

and the reason for this is because we need to make sure that no ticket is assigned to more than one user.

We can call this no double booking.

Sheesh, typing is bad.

No double booking, right?

So for any given ticket, we can only have one user sitting in that seat.

So consistency is really important for us there.

However, a more nuanced candidate, maybe a senior level candidate, would actually realize that these two things can coexist,

and I'm being very careful when I say that they can coexist, but in different parts of your system,

in different parts of your microservice and different parts of your system architecture.

So what I would amend this to is that we need strong consistency for booking tickets, but at the same time,

we want high availability for search and viewing events.

That's kind of the right, more senior answer there.

So when users are searching and they're viewing events, they should be highly available and it doesn't really matter

if an event was just added

and they don't immediately see it within a couple of seconds fine

but in the case of booking a ticket

100

if a user in germany bought a ticket that i'm viewing while i'm here in america

101

i need to know instantly that they booked that ticket

102

or get an error because i can't book that ticket anymore right

103

so strong consistency for booking tickets high availability for searching and viewing events.

104

What else is interesting in this system?

105

Well, we can ask ourselves first about the read -write ratio.

106

Is there anything unique there?

107

And in this case, we would recognize that reads are much greater than writes.

108

So it's probably like 100 to 1, maybe even 1 ,000 to 1,

109

probably 100 to 1 if our conversion rate for booking tickets is maybe around 1%.

110

So there's going to be a lot more people searching and viewing events than there are ultimately buying.

111

This is going to have consequences on our design that we'll see later on.

112

The next is like, think about how our site is used what's our query access pattern is often how i refer to it so

113

what are what's the frequency consistency irregularity with

114

which requests are hitting our system and what you would note is

115

that people don't book tickets to events all

116

that much it's kind of this regular even consistency uh until you end up having really popular events

117

and so when taylor swift's tour is about to go live

118

or the super bowl

119

or the world cup all of a sudden

120

you have tens maybe even hundreds of millions of people at your front door trying to get the same ticket

121

so in the context of scaling this is an example where you wouldn't just write scalability

122

but instead scalability is important but it's to handle surges from popular events specifically

123

and so we'll need to design with that in mind scale ability cool

124

awesome um so there's there's a long list

125

that you can keep going down these non -functional requirements um obviously it's important

126

that we don't use lose data

127

that we remain compliant with gdpr all of these sorts of things

128

but if all of that comes to mind what i usually suggest is

129

that you just note that as below the line so like out of scope uh you know gdpr oops gdpr compliance.

130

I'm not going to write all of these out, but fight fault tolerance, etc. You sort of get it.

131

And then once you've done this, you can say to the interviewer, these are what I'm going to prioritize.

132

Here's what I've considered out of scope.

133

Would you like me to reprioritize any of this?

134

Is there anything from down here you'd like me to move up here?

135

Anything from down here you'd like me to move down?

136

It's sort of a nice elegant way to make sure that you check in, you're on the same page with the interviewer,

137

and it shows them that you have this larger product thinking.

138

You think about all of these things that are necessary in designing a system

139

but you also can remain focused on on what really matters for this particular system sweet

140

so with that you've defined the functional and the non -functional requirements

141

so the next step is for us to define our core entities

142

and the api i'm doing sort of in the same step here

143

because they usually come hand in hand usually you won't spend more than like two minutes here on core entities

144

and up to five on api

145

but the purpose of the core entities is to start to

146

get an understanding of what data is persisted in your system

147

and then exchanged by the apis so this is really going to be useful

148

in order to you're going to use these in order to

149

build your apis as well as of course your high level design

150

so you can think here what are the core entities of a system like ticketmaster

151

Well, the first thing is we're going to have an event.

152

And so admins are going to add these events.

153

Note that adding events is going to be out of scope.

154

We're going to be focused just on sort of like the user flow for our system.

155

But users can add events.

156

Events themselves need to be hosted somewhere.

157

So they're usually hosted at a venue, like a stadium.

158

And then there's somebody who's performing.

159

There's a performer.

160

So we'll probably have tables for each of these or collections for each of these.

161

and then maybe most importantly you need a ticket

162

so we're gonna have a ticket table

163

and this is going to have all of the tickets for a given event

164

so that we can determine whether or not they're available who's purchased them

165

if they've been purchased their price stuff like that

166

so these are our core entities now one thing

167

that you can do is

168

that you know next to these you can mark down what all of their fields would be name description etc

169

if you know them at this point I usually suggest, and for me, if I was going and doing an interview right now,

170

I would just stick to the core entities and I would be clear to my interviewer,

171

like, I'm not going to detail the key fields and columns yet because the reality is I don't quite know them yet.

172

I'm too early in my design.

173

They're going to evolve naturally.

174

So instead, I'm just going to get a clear sense of what my core entities are.

175

And then as I move into the high level design, and you'll see this when we get there,

176

we'll be more explicit about exactly the fields that matter.

177

But for now, I would stop here.

178

And with the core APIs defined, I would move on to API.

179

And so these are, strictly speaking, the user -facing APIs.

180

These are the APIs that the client is going to be making in order to satisfy the functional requirements.

181

And so the way that you do this when you get here is

182

that you should look back at your functional requirements and create an API, or in some cases more than one API,

183

in order to satisfy each of these requirements.

184

And they should exchange change return take as input the entities or you know properties fields of these entities

185

so let's run through an example of that book tickets let's do

186

that one last maybe because it's the most involved let's start with the simplest view an event

187

so in order to view an event i'm going to have a git call

188

i'm going to use a rest api

189

that's what you'll typically do in these interviews in most cases

190

though you should consider other options graphql being being the main other one.

191

So I'm going to have get event and then I'm going to have this path param of event ID.

192

And so users can pass in an event ID and what they'll get in exchange is an event object.

193

They'll need to get information about that venue.

194

They'll need to get information about that performer.

195

This is everything needed for us to render a page about this event.

196

And then we'll also need a list of tickets.

197

This is going to be so that we can render the seat map.

198

So like what tickets are available, where's their seat, etc. So take in an event ID and return these entities.

199

That's going to be for viewing an event.

200

Very easy.

201

Now we can look back up here and we can go next for searching for an event.

202

So if you want to search for an event, you would do git.

203

Maybe we'll have a search endpoint.

204

And this search endpoint can take in things like maybe a search term.

205

This can be free text. So something like this.

206

And it would also probably take in a location and

207

so maybe this location is lat launch

208

i'm just going to have it abstracted as location for now maybe we have a type

209

or a category

210

so this is something like is it a sporting event music etc dot dot dot maybe

211

there's some other query params

212

that you would care about uh date is probably a really important one too right here like date ranges

213

these are all the optional fields that you can search for

214

and what this is going to return is that this is going to return, I'm going to use, this is just pseudo code here,

215

derived or inspired by TypeScript, but partial event, a list of partial events.

216

And the reason that I say partial here, and this isn't particularly interesting for the interview, you can denote this however you want.

217

But just so it's clear, this is because I'm going to return just a limited amount of information from that event, like the name, the description,

218

the performer, whatever it may be, because I just need enough to show those search results.

219

And then you'll click on those search results and hit this API endpoint to get the full detail.

220

But here's our search endpoint.

221

So we have a basic endpoint to satisfy viewing events, a basic endpoint to view searching for events.

222

And the last thing that we need to do is satisfy booking a ticket.

223

So this one's more interesting.

224

And the reason that I paused before coming back into this one is because you will notice, or it's important to notice,

225

that booking is actually a two -phase process.

226

So if you ever used a Ticketmaster or if you've ever bought an airline ticket,

227

you would know that what you usually do is you see a seat map or you see an airplane map,

228

you choose a seat, and then you go to a second phase where you're actually going to purchase that ticket.

229

And so in that second phase, you usually have a timer or a countdown, maybe 10 minutes, in order to actually purchase that ticket.

230

And for that 10 minutes, that ticket's reserved for you.

231

So you click on a ticket ends up being reserved you then have 10 minutes to actually book it

232

if you don't book it that ticket goes back to available

233

and that's the same pattern that we'll have here

234

so in an interview some candidates

235

because they have experience with these sorts of things they've thought about

236

that they know that they know that it's two -phase

237

and that's usually awesome to see but it's not a requirement

238

if i see that

239

that a user writes a single endpoint for booking a ticket

240

then i'll point out actually this is going to be a two -phase process and then they'll amend it accordingly

241

So what we'll end up doing here is we'll have some posts, and we'll maybe call it booking.

242

And the first endpoint is going to be just to reserve.

243

And this is going to take in, in the body, just a ticket ID.

244

And so there's variations of this problem, where maybe you can reserve multiple tickets, you can click on multiple seats.

245

We're going to make it simple, and just say there's a single seat that you click on, that seat's associated with a ticket,

246

and you're going to get that ticket ID as the input, and you're going to want to reserve it you'll notice

247

that i don't have user id actually in the body here

248

this is on purpose some candidates will put user id here on it it's it's a security concern

249

you wouldn't paste or post a user id in the in the request body

250

because that could be altered i could come in here

251

and then post a reservation on behalf of somebody else

252

so long as i knew that user id

253

so instead usually user information is kept in the header either via jwt or a session token.

254

And that's usually nice to note in your interview, kind of shows some technical excellence, but you don't need to spend too much time here.

255

Then the second thing that you're going to do, that's going to be your reservation.

256

This is going to reserve a ticket for 10 minutes, and the user client is going to go to a payment page.

257

And you're then going to try to fill out that payment.

258

And so now we'll have another endpoint to confirm.

259

Again, our header is going to have that JWT.

260

We're going to need the ticket ID to say which one we're confirming, and then we'll have some payment details probably and

261

so we'll offload this to stripe third -party payment services stripe has things called payment intents

262

which use common client libraries that you can set up either in react

263

or raw javascript whatever it may be in order to get this payment information

264

and this will be posted back then to your server

265

so we have our two endpoints just to recap for booking a ticket.

266

The first to reserve and the second to confirm.

267

And so maybe this isn't a post because we're not creating a new entry here.

268

Maybe this is just a put or a patch respectively, but certainly not the most important thing.

269

Awesome.

270

So that satisfies our core entities and our core APIs.

271

And then in the next section, we're going to use these APIs in order to build up our high level design.

272

All right.

273

So at this point, you should be about 15 minutes into the interview,

274

which leaves you about 20 minutes to do your high -level design and your deep dives, give or take.

275

Depending on your level, maybe it's taking you a little bit longer to get here, and that would be totally fine as well.

276

But the next step, we've done our requirements for entities and APIs.

277

Let's get into that high -level design.

278

So again, the high -level design's goal is to create a simple design that satisfies our three functional requirements.

279

So in order to do that, zoom out a little bit.

280

The first thing our design is going to have is the client, It's going to be the user that's interfacing with our service.

281

And then we're going to opt for a microservices architecture.

282

This is by far the most common setup in these types of interviews.

283

If you're not sure which to go with, which architecture to go with, microservices is probably the right call.

284

So for that reason, we're going to have an API gateway.

285

The API gateway's main responsibility is to take incoming API requests and route them to the correct server, the correct microservice.

286

It also does some other things.

287

We can note those it does authentication it often does rate limiting

288

and then of course as we just mentioned routing is that

289

that most important one so

290

when we build up our high level design what we're going

291

to do is we're just going to go one by one through our api requests

292

and of course our api requests map tap back to our functional requirements

293

so we can start with this one viewing an event what happens

294

when the client the user ends up having a git request to an event id in order to view an event

295

Well, let's draw that out.

296

So what would happen is first, they're going to hit our API gateway.

297

Our API gateway is going to route them to the correct microservice.

298

In this case, I'm going to call it the event crud service.

299

So while it's responsible for creating, reading, updating, and deleting events, most of those other crud operations are out of scope for this problem.

300

We're just handling that view path, but that would be handled in this microservice.

301

So that request is going to hit this service.

302

And then the service is simply going to read off of our database.

303

So we'll have a database here.

304

And this database is going to store those core entities that we talked about.

305

So we're going to have an event table.

306

Let me zoom in.

307

We're going to have an event table.

308

And that event table is going to...

309

have an id it's going to have a foreign key to a venue id needs to be held somewhere

310

there's going to be some performer

311

or team obviously it'll have a name description dot dot dot a bunch of different metadata

312

and then additionally maybe importantly it's also going to have a one -to -many relationship with all the tickets

313

so this isn't going to actually be the ticket information

314

this is just going to be foreign keys to all of the different tickets.

315

Cool.

316

So that's our event table.

317

They're less important, so we won't spend as much time on them, but we mentioned them.

318

So we'll have a venue, which will have an ID.

319

It'll have some location.

320

It's probably going to have a seat map, some stuff like that.

321

Oops.

322

And then we'll also have a performer.

323

It'll have an ID dot, dot, dot. Who cares?

324

You know the details there.

325

Cool.

326

And then while we'll probably come back to it um you know we'll also have our ticket table

327

and that ticket table will be an id per ticket probably a seat price etc right

328

so seat here is like the location and then of course

329

it's going to have a relation back to an event so this is everything that's stored in this database

330

we can opt for you know here's where that sql no sql conversation comes in

331

i'll talk a little bit about why that's probably not relevant

332

but at least for this database

333

we talked about consistency being important for tickets in particular there's obviously some decent relationships between this data we've shown

334

that now one to one one to many so these are the properties

335

that matter to us i'm going to go with postgres a sql database under the justification

336

that one it's it's one that i use frequently

337

and it certainly satisfies our requirements here for acid properties on tickets allows for the ability to do transactions

338

and you know it's it's good for these sql queries where we'll have to have some

339

mild relationships but it's worth knowing

340

that like a no sql database would have been fine here too you could have chose dynamo db

341

and actually in your interview no sql versus sql is kind of an old debate like it's it's not

342

that interesting um what's more interesting is the qualities of the database

343

that you need because the reality is most of the things

344

that a sql database can do a no sql database can do nowadays

345

and most of the days that it's things that a sql database can do a NoSQL database can do.

346

So you can have ACID properties on DynamoDB, for example, totally fine.

347

Actually, in the interview, it sometimes, not even sometimes, it shows the candidate's seniority when they understand that that's kind of not a relevant debate.

348

Like many mid -level candidates will go SQL versus NoSQL and sort of try to break all of this down.

349

Whereas the more senior candidates just say, here are the qualities of the database that I need.

350

Either of these would have worked in this case.

351

I'm going to go with Postgres because it's the one

352

that I'm most familiar with and it'll do just fine for the job cool great

353

and we move on so this is this is

354

that appropriate time to map out the fields and the columns I mentioned

355

that we would come back to this at this point I put them right next to my database

356

because typically they evolve and you'll see this they'll evolve in this design too

357

but this is what we know for now so coming back to

358

that git request a user is going to want to view an event so they're going to hit our event crud service,

359

we'll get the event details, the venue and the performer from a join, as well as, you know, the tickets that are available,

360

and we'll return that back to the client.

361

So very simple.

362

That satisfies our first API endpoint here.

363

The second one is our search endpoint.

364

Our search endpoint for that, let's do this.

365

I'm going to move these down a little bit, maybe.

366

okay and then i'm going to add a search service so i'm going to add a search service

367

and for now in our high level design i'm going to do this as simple as humanly possible

368

and that means that i'm just going to do this

369

so a user is going to search for something let's maybe copy this

370

so that it's close and clear they're going to search for something

371

and at least based on term type date etc this can just be a sql query

372

so it can be something like select star from our DB where type in whatever and term or you know name like

373

whatever our term is you kind of get the picture here

374

this would work now for what it's worth this totally sucks

375

and it's incredibly slow and the reason it's incredibly slow is these wild cards here mean

376

that we need to scan this entire database.

377

You need to do an entire DB scan to see if any of the names match whatever term was inputted here.

378

That's not going to cut it, but for now, in my high -level design, I'm going to leave it like this,

379

and I'm going to come back to this.

380

And I might even say that in the interview.

381

I'm going to say, this isn't going to cut it.

382

I'm going to come back and optimize this once I've satisfied all of my functional requirements first.

383

So that's our very simple search case.

384

The last thing that we need to do is we need to satisfy booking.

385

So again, two -step booking flow.

386

Reserve a ticket and then confirm the purchase of that.

387

So in order to do this, I am going to add a new service, which is going to be my booking service.

388

And so that first request is going to come in.

389

This is going to be that kind of reserve request.

390

that reserve request comes in.

391

And what do we do?

392

The first thing that we do is we update our database.

393

This is going to be a single direction.

394

We update our database here, such that for this ticket ID, remember this reserve came with a ticket ID.

395

So for this ticket ID, we'll look up that row in our table.

396

And then we'll update a status column.

397

So we'll add a new column for status.

398

And this is going to be either available, reserved, or booked.

399

And so we'll update it in this case to reserved

400

and then our user will return to the client saying success 200

401

and then the next request that's going to come in is

402

that purchase request or

403

that confirm request it's also going to take in a ticket id as well as those payment details right so

404

that guy's going to come in now we're going to use

405

stripe a third -party payment processor in almost all of these cases

406

you can abstract out away the payment unless it's an interview that's like specifically for a payment team

407

or has specifics to do with you needing to design a payment system.

408

But we're just going to use Stripe.

409

Because it's interesting, the way that this works is that you actually call out to Stripe with the payment information.

410

You're going to post to Stripe and then

411

Stripe is going to handle that payment asynchronously.

412

It needs to call out to the credit card companies, determine whether or not it can be paid for.

413

It happens very quickly for what it's worth, but it handles that asynchronously.

414

And then it calls back to your system, not by responding to this single request, but actually via a webhook that you've set up.

415

So you're going to register a callback URL, and you'll have some endpoints in your booking service.

416

Wrong way around.

417

You'll have some endpoint in your booking service, which is exposed, for this to call back to.

418

So just good to know, but not necessary maybe for the interview.

419

The point is we'll get the payment information.

420

We'll call out to Stripe.

421

Stripe will handle that, reach out to the credit card companies, et cetera, the banks, and then respond with what happened.

422

And it's going to respond.

423

If that response is that it was successfully able to pay, then great.

424

What we're going to do then is we're going to reach back out to our database, go to the ticket table

425

and update this status now to booked amazing

426

and it would probably not only be booked

427

but we'll also have like a user ad here who actually booked it

428

and now this ticket is no longer available it's assigned to

429

that user maybe we'd send them an email all of this i'm going to consider

430

that out of scope but that's what's going to happen in the happy path here

431

so this is sort of our high level design

432

but astute listeners watchers would have realized that there's something wrong with this two -phase booking process right now.

433

And specifically, what's wrong is that if a user were to click on a seat and then go to the payment page,

434

and on the payment page, they have that 10 minute countdown.

435

What happens if that 10 minutes is exceeded?

436

What happens if they just close their laptop and we're done?

437

They decided they didn't actually want this ticket.

438

Well, in our case, what would happen is that this status would stay reserved forever.

439

And what that means is that when we show users the seat map, we'd be querying our database for tickets that are available,

440

which would exclude the reserved, of course.

441

And that seat would basically just be infinitely reserved for that user, which is wrong.

442

And that doesn't meet our requirements of it needing to expire after 10 minutes.

443

So how could we handle that?

444

The first thing that we could do is that we can add an additional column here with the timestamp of when,

445

oh my gosh, with the timestamp of when this thing was reserved.

446

So reserved timestamp.

447

And now what we can do is that when we read the database to see what's available,

448

this query would look like select all tickets where the status is available and or excuse me,

449

or it's reserved, but the reserved timestamp is more than 10 minutes ago.

450

So we made this query a little bit more complicated, but this would absolutely work.

451

Now, this is an okay option.

452

The one downside of this option is that you make your database and your data model here a bit confusing.

453

You have a status of reserve while things aren't actually in a reserve status, and you need to keep these two things consistent with one another.

454

That sort of sucks.

455

So there's something else that we can do, and we can introduce, for example,

456

a cron job here, and this cron job might run every 10 minutes or so, and it's responsible for querying the database for every ticket.

457

querying the database for every ticket that's in a reserve status, and then checking its reserve timestamp.

458

And if it's been more than 10 minutes since the reserve timestamp, then it's going to set the status back to available.

459

So that's what this cron job would do.

460

Now this works and is totally a valid approach.

461

And in fact, for mid -level candidates, this is kind of a passing approach for the interview.

462

Now for senior and certainly staff, principal and beyond, this wouldn't quite be enough

463

and the reason it wouldn't be enough is because there's a delta

464

that gets introduced here we'll call it n between the time

465

when a ticket should have been unreserved and the time

466

when our cron job ran so if our cron job ran every 10 minutes

467

or so and we had a ticket

468

that was supposed to be unreserved at noon

469

but our cron job didn't run again until 1209

470

then n equals nine we had nine minutes where this thing was should have been available

471

but instead it was reserved

472

and ultimately the ticket was reserved for 19 minutes not just 10 as was expected

473

so we need something that's a bit more real time

474

and to do this we can do something a bit more sophisticated

475

we can get rid of the cron drum

476

we can actually get rid of the reserve time stamp as well as well as this reserve status

477

and instead we're going to introduce a distributed lock so we'll call this our ticket lock.

478

And we can use Redis.

479

You can use kind of any in -memory cache here.

480

But what this is going to be used for is that when a ticket gets reserved, instead of updating our ticket table at all,

481

we're just going to keep track of that here.

482

And we're going to keep track of it with a TTL.

483

So we'll have some key value pair of ticket ID to maybe just a Boolean of true.

484

That part doesn't matter.

485

And then a TTL of 10 minutes.

486

And so that means that after 10 minutes, this key value pair is immediately going to be deleted from our database

487

so how would this work when a user tries to reserve a ticket from

488

that first api request we're not going to write to the database at all instead we're simply going to put

489

that ticket in our lock we're going to lock

490

that ticket for 10 minutes by setting the ticket id with a ttl of 10 minutes awesome now

491

if 10 minutes elapses or actually maybe let me knock you my head of myself by doing

492

that we know now things are locked and

493

so in our event crud service

494

when we want to for a given event get all of the tickets for

495

that event and see whether

496

or not they're available we would need to first query our database for all tickets

497

that have a status of available

498

and then for each of those ticket ids we would need to look them up in redis to see

499

if they're reserved if they are we would remove them from

500

that list of available tickets

501

and send it back to our client great now in the case of that user who closed their laptop,

502

you know, before they were able to confirm their payment, this is going to expire immediately at 10 minutes.

503

So if a user at 10 minutes and one second, 10 seconds, whatever it wants is going to be,

504

queries to get our seat map again and to get the available tickets, now when we cross -reference it with a ticket lock,

505

that ticket ID is no longer going to be there.

506

And as a result, that ticket is going to be available

507

and it's going to be shown to the client for them to be able to book it.

508

Easy.

509

So this is a super easy, elegant solution to use a distributed lock here.

510

And the reason

511

that we use a distributed lock as opposed to maybe just keeping this in memory in the booking service is

512

because there's going to be multiple instances of this booking service, right?

513

This isn't a single machine.

514

This isn't a single compute resource.

515

This is going to horizontally scale.

516

And they all need to have the same consistent singular view of the lock.

517

And so that's why we separate this out and have it as kind of as its own in -memory cache here.

518

Hopefully that makes sense.

519

It's sort of the optimal answer.

520

I'll mention just quickly, sometimes candidates will ask or want to go into where an interviewer may ask, like, what happens if this lock goes down?

521

Well, if this lock goes down, then you would have the following issue.

522

One, we'd immediately bring a new one up.

523

We would detect that this is down and we would immediately bring a new one up.

524

But that means that any users that reserved a ticket in that last 10 minutes lost their reservation.

525

And so in theory, for a 10 minute window, we could have several users go to a payment page and try to book the same ticket.

526

Now, because this is a Postgres DB here, and we still have the ACID properties on the right to available or booked,

527

meaning one write needs to complete before another one could read it, whoever ends up submitting that purchase first is going to win.

528

And the other one's going to get an error.

529

And this is a bad user experience.

530

It sucks for those users in that 10 minute window, they're going to have a bad user experience.

531

And this is a conversation that we would have with the product team.

532

Like, is this okay?

533

Is it okay that in the likely event we have a disaster where our lock goes down,

534

then we'll have a small 10 minute period where we're not going to lose our consistency guarantees,

535

but our users are going to have a bad experience.

536

And I would probably argue that this is fine for what it's worth.

537

Okay.

538

So this is now our high level design.

539

This satisfies all of our functional requirements.

540

It's not perfect.

541

It doesn't scale.

542

Searches is not great, but we'll handle all of that next in our deep dives.

543

okay now for the fun part so with the deep dives this is where senior

544

and staff and particular candidates really earn their keep

545

if you're a mid -level candidate what you have right here on the board already might be passing especially

546

if you got that reddish lock most mid -level candidates don't get

547

that far most mid -level candidates land on the um on the cron job solution that we discussed

548

but you're close here

549

if you're a mid -level candidate your interviewer might ask you

550

a little bit more about how you would scale the system

551

they might ask about search being slow etc answer those questions well

552

and you probably have this in the back in any case especially for senior

553

and staff candidates this is the place where you're going to show off your chops we're going to show off

554

that you can go deep

555

and your goal should be to find one to three places where you can show off

556

that depth I'm going to go into detail on a couple of such places

557

but by no means are these the only places

558

they're not the ones an interviewer is explicitly looking for it's

559

really up to you to decide where you lead the conversation from here now the process

560

that you should take when you hit the non -functional

561

or excuse me when you hit the the deep dives is to reference your non -functional requirements

562

and look at them and see what's missing and

563

that should really inform where you go next with your deep dive

564

so we talked a lot about how search wasn't optimized

565

and that's the first place that i want to start

566

and actually you'll notice that i went back and added it here already

567

but we originally didn't have low latency search and this was a miss

568

so this was something

569

that i missed originally in the non -functional requirements i realized it as i was designing the system

570

and it's totally okay to go back and edit it that's something

571

that you can do and should do in the interview that's great

572

so it's the first one that we're going to handle here low latency search

573

so we come back and our current solution we know is slow the current solution is slow

574

because we do a full table scan on a query like this

575

so this is our api endpoint for search i'm going to move

576

it out of the way i'm going to delete that

577

and the common solution to search problems like this is to introduce a search optimized database

578

and a very popular one and one

579

that i recommend you use in your interviews is called elastic search

580

and so the way

581

that elastic search works is along with other things it builds an inverted index to make searching documents by terms really quickly.

582

So you can imagine that we have an event.

583

An event has some text for the name and the description and maybe all of these other things that describe the event.

584

And what we're going to do is we're going to tokenize

585

that string or those sets of strings and create terms from them.

586

So you could imagine that the string might be the Philadelphia Eagles are playing in a wild card matchup against the Broncos,

587

this, that, and the other.

588

I guess that couldn't happen NFC versus afc

589

but uh you get my point we would turn

590

that into uh philadelphia eagles playoff wild card all those terms

591

and then we can map those in a hash map of sorts to the documents

592

or in our case the events that those show up in

593

so the word playoff shows up in event one event two

594

and event three and then maybe the word swift like taylor swift shows up in event five event six six

595

and event n you get the point and

596

so now you have this really quick lookup such that

597

if somebody searches in description for playoff then we can easily return to them all the events

598

that mention playoffs and show them the relevant events based on their search term

599

and this can be combined not just on description not just on name

600

we would probably search term on each of those

601

elasticsearch also has support for geospatial queries it actually uses a combination of quad trees and geohashing if I'm not mistaken.

602

Don't quote me on that, but I'm pretty sure.

603

And so you can do these sorts of things like searching for location and terms and dates at the same time.

604

And we'll use the varying indexes that it's created, whether these inverted indexes or geospatial indexes to make it as quick as possible.

605

So Elasticsearch is a really effective solution to make these search queries as quick as possible.

606

So we can delete this line and instead we'll search using elasticsearch

607

and so then the question becomes how do we get data into elasticsearch

608

and how do we make sure that that data is consistent with what's in our primary database

609

and so it's important to note

610

that it's not best practice to use elasticsearch as your primary data store

611

this is usually on the back of durability concerns

612

and it has no support for like complex transaction management um actually

613

we use the elasticsearch um as a primary data store for our first startup

614

and we learned the hard way that it didn't work out very well

615

so i know this from first -hand experience so as a result of

616

that we need some way to make sure that

617

if anything changes in our primary database that change gets propagated to elasticsearch and so

618

So there's a couple of ways that we can do that.

619

The simplest way is that we just handle this all in our application code.

620

So in this case, anytime an event is added, anytime an event is added,

621

we'll write it to our Postgres DB and we'll also write it to Elasticsearch.

622

Now, this puts some complex logic, kind of complex logic in your application code here,

623

because you'll need to make sure what happens if this write fails, then you don't want this write to happen.

624

What happens if this write fails, then you probably need to retry this write or back out, reverse that first write.

625

So there's some things to consider there depending on your product requirements, but that's definitely a viable solution.

626

Another common solution that you'll see pop up a lot is using what's called change data capture.

627

so change data capture or cdc as it's often referred to is a process for

628

which changes to a primary data store can be put onto a stream

629

and then those change events can be consumed

630

and something can be done with them so in this case anytime something changes

631

that change event will be put on a stream we can consume it

632

and then update elastic search with whatever that change was

633

so in interviews this is oftentimes just abstracted to be this you know you can just do

634

that technically speaking like this is a large abstraction you know

635

this is a stream there would have to be some worker

636

that does the right here

637

but oftentimes this is good enough in the interview you might want to clarify

638

that this is an abstraction but

639

that would work well the one thing to be aware of with cdc

640

and particularly with rights to elastic search is

641

that it has a limit on the number of writes that it could take per second because it's updating these indexes, right, in each write.

642

So for services that your systems that you're gonna be designing for which there are a lot of updates to Elasticsearch,

643

then you'll need to do something smarter here, like have a queue, have some batching, whatever.

644

But in our case, you would note in the interview that events, venues, performers, like these don't change a lot.

645

They hardly ever change.

646

And not only do they not change a lot, but they're hardly ever added.

647

Maybe at most an admin adds tens, hundreds, maybe even thousands a day, but that's absolutely nothing.

648

So we don't necessarily need the queue there.

649

We can just update Elasticsearch on each change to our primary database.

650

So in doing that, our search is pretty dang quick.

651

This is great.

652

The introduction of Elasticsearch was perfect.

653

I'll spend just a moment going into how we can make this maybe even faster.

654

Your interviewer might ask you, what about popular queries?

655

What about if everybody is searching for Taylor Swift, how can we make that as quick as possible?

656

So the answer to that is usually caching.

657

Now, you need to recognize that in our system, we're not doing any ranking or recommendations for users.

658

So if two users search for the same thing, they're going to get the same result.

659

And that's important.

660

And that's very important to note for caching, of course.

661

And so there's a couple of ways that we can handle this.

662

The first is that for Elasticsearch here, you might be using and you probably are using OpenSearch.

663

AWS is OpenSearch.

664

This is like a fully managed Elasticsearch cluster.

665

And OpenSearch supports something called node query caching.

666

I believe that's what it's called.

667

Again, maybe don't quote me, look that up.

668

But I think that's what it's called and what this is is

669

that this is a cache on each of the instances of your elastic search cluster each of your shards

670

and it caches the top 10k queries to

671

that shard in a least recently used cache so you can enable

672

that i think just via the config

673

and that's a great option quick dirty easy

674

and that's going to work great so that's kind of option one another thing

675

that can do of course is that you could add redis or memcache here and you could cache your search term

676

or some normalization of your search search term as well as the search results

677

and then that would work fine as well then you just need to make sure

678

that you invalidate appropriately when there are updates made things like

679

that so that's an option another option and the option

680

that i would probably take here just because it's it's quick

681

and easy is that your system probably already has a cdn for the static images, which was out of scope for us,

682

but, you know, most systems will have it.

683

And so we can have a CDN here.

684

And what the CDN is going to do is that the CDN can cache these API calls.

685

So it can cache this API call and its results.

686

And usually when you cache an API endpoint in a CDN, it's for a short period of time,

687

30 seconds to a minute or so. But that way, a lot of people are searching for the same exact search term

688

then you can just return those results immediately by hitting

689

that cdn which is of course geographically located close to them

690

so this is wicked fast um a couple downsides to note here pros

691

it's super fast it's great for those super or popular events in particular, but this becomes less useful.

692

more permutations you have of your search query

693

it's like we already have a lot of things here type date location

694

if this was lat launch then this would kind of take this out of the picture

695

because it would be a user's lat launch

696

that would have too much precision

697

and thus we would never have any overlap two users would never hit the same

698

but if this was something like san francisco okay and then turn

699

and so like maybe that would be small enough

700

that you would have enough cache hits but the more query terms

701

that you have here the more query params the less likely you're going to get cache hits

702

and the more likely that you're just wasting space in the cdn

703

so that's definitely something to consider and then of course as i mentioned earlier

704

if the system evolved such that it gave personalized recommendations then this wouldn't suffice

705

because this would mean

706

that everybody who searched the same um

707

you know search with the same api call here they would get the same results

708

and that wouldn't be true for our system anymore

709

because people should get personalized results so these are all the sorts of things

710

that you can mention in the interview

711

and it's impressive just to throw some of these things out there if they're contextually relevant okay

712

so we talked a lot about search

713

there that's the search deep dive looking back at our non -functional requirements low latency search check we met

714

that okay great i'm actually going to go out of order here just

715

because i want to focus on maybe some of the most fun and interesting ones

716

and I'm going to go to scalability to handle surges from popular events.

717

So let's take a moment to lead the conversation then in that direction.

718

So the first thing that you'll notice is taking a step back and focusing on the user experience.

719

When a user comes to our website and they click on an event, they're going to see those event details about the event venue performer,

720

and they're going to see a seat map.

721

And the seat map is going to show them seats that are available and seats that are already booked,

722

and they can click on those that are available.

723

And so the way that this would work in our system right now is that they would query our event cred service.

724

We would query to get our event venue and performer.

725

And then we would query to get the tickets for that event with their available or book status.

726

And then we would need to cross reference that available or book status with tickets that might be in our lock.

727

So anything that's in our lock needs to be moved from available to reserved or just booked so that

728

the client knows that it can't book it.

729

So we would do all of that

730

and give it back to the client now the issue with this is

731

that we made that api call we loaded that up on the client

732

and now immediately the client sees an accurate representation

733

but after one second two seconds five seconds five minutes ten minutes it's grown stale

734

and now they can be clicking on seats that appear to be available

735

but they're no longer available

736

and we're going to have to immediately give the user an error

737

and that's a really bad experience so particularly for these more popular events

738

that would happen a lot like a lot of people are buying tickets so it could go stale really quickly.

739

So the first thing that we could do here is we could try to make that map real time.

740

And this means that anytime a ticket becomes reserved or moved to book,

741

then we update the client to mark that seat in real time as no longer available.

742

And we could do that a couple of ways.

743

The first thing that we could do and would probably be the most simple is we could just use long pulling.

744

So long pulling is the client opens up or sends in an HTTP request.

745

And then that request is kept open for usually like 30 seconds to a minute

746

or so for the server to be able to respond.

747

And this can happen in a while loop.

748

So you kind of just keep long pulling, keep long pulling.

749

So the server can keep sending things back and keep sending things back.

750

And in our case keep the seats updated

751

so that's one option it would be super cheap it's easy to implement requires no additional infrastructure especially

752

if users are not on this page for a long time

753

this is great if users are on this page for a minute to five minutes this is perfect

754

if we find from our analytics

755

that users sit on these pages for a really long time 5 10 20 30 minutes hours

756

then we may need a slightly more sophisticated approach and that sophisticated approach could be to open up a persistent connection.

757

So your mind might have gone to WebSockets, and that would be an option.

758

A WebSocket is a bi -directional persistent connection.

759

But instead, we could probably go for server -sent events or SSE.

760

And so while not similar maybe in implementation, they're similar in that they are a persistent connection between the client

761

and the server such that the server can send information to the client not only

762

when the client sends a response so in the beginning open up

763

that connection and then the client or the server can push information over

764

that ssc connection kind of whenever it wants

765

so long as the connection is still open

766

and the difference the key difference aside from their implementation between web sockets

767

and ssc is that web sockets are fully bi -directional ssc is unidirectional

768

so it's only server to client and that's all

769

that we need here right we only need our server to be able to tell our client

770

that new seats have been taken so that's something that

771

that you could do

772

and you could talk about this in the interview

773

i'm going to set up ssc connections persistent connections between my api gateway

774

event crowd service and my client

775

and every single time there's a change to either of these on the status of available

776

or booked or on my reserved i'm going to push

777

that change over to my client

778

and the implementation there is actually a bit more complex it's probably out of scope for this interview

779

but that's kind of the degree

780

that you would probably go into um that'll be fine

781

and then your interviewer might point out or maybe you would notice proactively that this is great but when Taylor Swift,

782

the Super Bowl, the World Cup comes around, the user experience is going to be that they get to that page and it immediately goes black.

783

They'll see all these available seats and then within a couple of milliseconds, it's just going to go black because everything got booked

784

because you had 100 ,000 or a million people trying to fight for the same 10 ,000 to 100 ,000 seats.

785

And so that's not great.

786

So what can we do to fix that issue now?

787

The solution there is that we need to introduce a choke point.

788

We basically need to protect our backend services, introduce a choke point, improve the user experience by doing so.

789

And that choke point would be by way of what's referred to as a virtual waiting queue.

790

So what you would end up with is, let's see if I can make room for this.

791

You can move all of this over and introduce here a virtual waiting queue.

792

And so this virtual waiting queue could be only enabled for really popular events.

793

Maybe it's admin enabled.

794

There's some config here and an admin determines what events we should introduce a virtual waiting queue for.

795

But at a high level in abstraction,

796

what happens is that you have a million people or so that all try to buy the Taylor Swift tickets.

797

And instead of seeing that event detail page, they enter a waiting queue and they get a message that says, thanks for your interest.

798

You're in the queue.

799

We'll let you know when you're out.

800

And they get put in this queue.

801

And this queue could just be Redis here.

802

that'll probably be a cheap lightweight implementation you can use a redis sorted set

803

so that it's a priority queue based on the time

804

that they arrived other implementations make this random

805

so it's a bit more fair

806

and it's not just the users who are closest to our company servers

807

that maybe get in first but in any case you'll have

808

that set and then you'll probably have some event -driven logic such

809

that you know once we have a hundred seats booked

810

we let the first hundred people in once we have a hundred seats

811

that are booked we let the next hundred or thousand, whatever it may be.

812

And you pull those people off of the queue.

813

Maybe you put their user ID or their session, or you assigned them a token and you pull that off this virtual waiting queue.

814

And then you can notify the users maybe over that same SSE connection that you created prior that they're ready to go.

815

And then that user can be let in and that user can book.

816

So this is actually a really nice example where this is a simple solution.

817

It's a simple solution, but it's a sophisticated solution.

818

And it shows that oftentimes, like the best answer isn't the most technically complex.

819

But instead, it solves the problem in a simple and maybe creative way.

820

So the virtual waiting queue there is great.

821

Okay, those are those are some great deep dives.

822

We can come back and look strong consistency for booking tickets.

823

We actually already covered that in our functional requirements.

824

When we were dealing with booking, we introduced our Redis lock so we we got to

825

that one early we covered that we have strong consistency that's wonderful

826

high availability for searching

827

and viewing as well as our read to write ratio being in the favor of reads significantly

828

so this is where you might just get the normal questions of like how would you scale the system

829

or maybe you proactively talk about it as an interviewer i usually find these discussions kind of the least interesting and that's

830

because here's what you're going to say you're going to say something like i use aws api gateway here

831

which is managed it has its own load balancers

832

so this is scaling each of these have their own load balancers

833

and dynamically scale based on memory consumption or cpu consumption

834

so these scale horizontally that's great for my databases here maybe

835

you talk about sharding

836

this would be an appropriate time actually to even do some

837

math actually quick aside on math astute watchers might have realized

838

that I didn't do any back -of -the -envelope estimations after my non -functional requirements.

839

This is on purpose.

840

I actually recommend this.

841

So most candidates will do some back -of -the -envelope estimations there, and it'll be things like QPS and daily active users and storage,

842

and at the end of it, they'll go, wow, okay, it's a lot, so it's going to be a big system, and then they'll keep going.

843

I didn't learn anything about the candidate.

844

The candidate didn't learn anything that would inform their design.

845

They were just checking a box, so I considered this useless.

846

I considered this math without a purpose.

847

so math is good but my recommendation is that you only do calculations

848

if the result of the calculations will have a direct influence on your design

849

and usually the right time to do

850

that is either in your high level design or in your deep dives

851

so for example maybe i do some math here now

852

and i won't because i don't want this video to go a little too long

853

but I could do some math to see what the storage is here in this PostgresDB

854

to make a determination as to whether we need to shard or not, or it could fit into a single Postgres instance.

855

And so if I came to the conclusion that we did need to shard,

856

then I would have a conversation about what I need to shard on.

857

And maybe that's event ID, because that's what the majority of my queries are in.

858

Or if we're sharding and then distributing these shards geographically, maybe I do it over venue ID.

859

If there's high correlation between people searching for events that are in venues close to them, then maybe that makes sense too.

860

So you would weigh that.

861

Again, no right answer.

862

It's a discussion maybe to have with the interviewer, weigh the pros and cons, but that's something that you could talk about there too.

863

So that's the general scaling conversation.

864

And then given that reads are so much higher than writes,

865

another thing that we could do is to reduce the read load on our Postgres DB here.

866

And especially because event venue and performer never change or very infrequently change, it makes them a great candidate to just cache them to hell

867

so we could have redis here and we can cache those events venues

868

and performers in redis make sure that

869

if we make any updates to our database then we'll have to invalidate

870

or update our cache as well there doesn't need to be an eviction policy like least frequently used

871

or least recently used or anything because we probably fit them all in there

872

or maybe we just do events that are you know upcoming

873

or within the last four months

874

and in the next two years whatever maybe you introduce some bounds there but now this makes this view api call

875

this one wicked fast

876

because we can just cache a key value pair of an event id to the event venue

877

and performer relevant to it

878

and then we only need to make a query to get tickets

879

because that's the one that's dynamic so we'll not cache

880

that one in this case awesome um okay

881

so that's a little taste of some of the deep dives

882

that you could do i think what we end up here is a pretty solid design

883

if you did this you certainly pass a mid -level interview with flying flying flying colors

884

this is overkill for a mid -level interview by far

885

you definitely pass a senior interview that's great

886

you probably pass a staff interview depending on how well

887

you executed how well you were able to answer some questions

888

and if you showed some depth in other places and you know principles is usually evaluated at the same level of staff.

889

So you pass that as well.

890

Okay.

891

Last thing here is that when you conclude, you should be able to look at your design concretely.

892

And you should be able to say, does this satisfy all of my functional requirements?

893

And does it satisfy all of my non -functional requirements?

894

If you can say yes to both of those things, then you should feel confident.

895

Just put your hands up.

896

You should say, I know I passed this interview.

897

I can't wait to the call back obviously don't say that

898

and you're probably hired so that's the the process

899

that you should follow all right thanks everyone for watching i really hope you found this valuable

900

if you did let me know in the comments i want to do more of these

901

and if people are finding value out of them then that'll encourage me to keep pumping them out also

902

if there's anything that i did wrong

903

if you think was silly was a bad design decision or

904

if you just have general questions please leave those in the comments I'd love to chat about it

905

but thanks so much for watching and good luck with your upcoming interviews take care

Baixar aplicativo

Tudo o que você precisa para falar fluentemente

Pronúncia com IANota em cada frase

Prática de IPADomine cada som

VocabulárioMonte seu banco de palavras

Jogo de vocabulárioAprenda brincando

Escaneie o QR

Download on theApp Store Get it onGoogle Play

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

Redis Deep Dive w/ a Ex-Meta Senior Manager

Business EnglishUniversity StudentsWorking Adults

Recommendation System Infra Basics 1

Business EnglishUniversity StudentsWorking Adults

Consistent Hashing: Easy Explanation for System Design Interviews

Interview EnglishUniversity StudentsWorking Adults

FOR YOU

Vídeo recomendado

324 frases

Distributed Task Scheduler: System Design Interview (Stripe & Amazon Offers)

Business EnglishInterview EnglishUniversity Students

392 frases

Uber Data Engineering Mock Interview - Ride-Sharing Data Warehouse Schema

Interview EnglishUniversity StudentsWorking Adults

99 frases

How to Answer System Design Interview Questions (Complete Guide)

Business EnglishInterview EnglishUniversity Students

8 frases

Google product manager behavioral interview (Top 5 questions)

Interview EnglishUniversity StudentsWorking Adults

293 frases

Is AI Killing Human Fashion Design? Who Will Shape the Future of Design? Fashion Tea #6

Daily ConversationUniversity StudentsWorking Adults

715 frases

Mastering iOS Development: Mock Interview with Ramiro Neto

Business EnglishInterview EnglishUniversity Students

160 frases

[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008

TOEFL PrepBusiness EnglishInterview English

231 frases

My Senior UX Design Interview Experience | tips, questions, prep, & more!

Business EnglishInterview EnglishUniversity Students

205 frases

Solving Easy SQL Interview Questions on Analyst Builder

Interview EnglishUniversity StudentsWorking Adults

198 frases

2025 DevOps, SRE, Cloud Engineer Interview Questions: Ace Your Interview with This Guide

Business EnglishInterview EnglishUniversity Students

Vocabulário e dicas de fala para esta lição

Esta aula de conversação usa o vídeo “System Design Interview: Design Ticketmaster w/ a Ex-Meta Staff Engineer”. As palavras que mais se repetem: event, ticket, user, search. Este vídeo tem 905 frases e 11404 palavras para praticar shadowing. A fala dura 58:38. O falante fala rápido, cerca de 194 palavras por minuto, então espere sons ligados e reduzidos. 86% das palavras estão entre as 3.000 mais comuns do inglês; vale a pena estudar o restante antes de começar.

Vocabulário principal deste vídeo

15 palavras do vídeo que vale a pena aprender, com pronúncia e significado:

Palavra	Pronúncia	Significado
database substantivo	/ˈdeɪtəˌbeɪs/	banco de dados, base de dados
functional adjetivo	/ˈfʌŋkt͡ʃənəl/	funcional
query substantivo	/ˈkwɪɹ.i/	pergunta
cache substantivo	/kæʃ/	esconderijo
entity substantivo	/ˈɛn.tə.ti/ [-tʰi]	entidade
satisfy verbo	/ˈsætɪsfaɪ/	satisfazer
queue substantivo	/kju/	fila, alinhamento
interviewer substantivo	/ˈɪntɚvjuɚ/	entrevistador, entrevistadora
venue substantivo	/ˈvɛnjuː/	sala de eventos, salão de eventos
dive verbo	/daɪv/	mergulhar
consistency substantivo	/kənˈsɪs.tən.si/	consistência
server substantivo	/ˈsɝvɚ/	servidor, server
stripe substantivo	/stɹaɪp/	listra
introduce verbo	/ˌɪntɹəˈdus/	apresentar
scope substantivo	/skəʊp/	âmbito, escopo

Phrasal verbs que você vai ouvir

Palavra	Pronúncia	Significado
end up verbo		terminar, acabar
go down verbo		descer
come back verbo		voltar
set up verbo	/ˌsɛt ˈʌp/	preparar
show off verbo		mostrar-se, jactar-se
point out verbo		apontar
check out verbo		verificar, sacar só
come around verbo	/kʌ.məˈɹaʊnd/	mudar de ideia

Frases que vale a pena repetir

Frases curtas e completas do vídeo que você pode usar na conversa do dia a dia:

We'll call this viewing an event.
Would you like me to reprioritize any of this?
Anything from down here you'd like me to move down?
What happens if they just close their laptop and we're done?
Your interviewer might ask you, what about popular queries?

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 result of the calculations will have
Present perfect have/has + particípio passado — uma ação passada que ainda importa agora	i've probably asked · i've seen · I've done
Voz passiva be + particípio passado — o foco está no que acontece, não em quem faz	is asked · is assigned · was just added
Orações relativas who / which + oração — informação extra sobre uma pessoa ou coisa	ones that are · venue, which will · service, which is

Pronúncia para ficar de olho

O falante usa 297 contrações e formas reduzidas, como we'll, I'm, we're. Diga-as na forma curta, do jeito que você ouve.

Os sons de “th”: mathematics /mæθ(.ə)ˈmæt.ɪks/, theorem /ˈθiərəm/
Os sons de “sh” e “zh”: cache /kæʃ/, implementation /ˌɪmplɪmənˈteɪʃən/, partial /ˈpɑɹʃəl/, reservation /ˌɹɛz.ɚˈveɪ.ʃən/, capture /ˈkæp.(t)ʃɚ/
Palavras longas — acerte a sílaba tônica: entity /ˈɛn.tə.ti/ [-tʰi], consistency /kənˈsɪs.tən.si/, availability /əˌveɪ.ləˈbɪl.ɪ.ti/, mathematics /mæθ(.ə)ˈmæt.ɪks/, implementation /ˌɪmplɪmənˈteɪʃən/

Sons difíceis para falantes de português:

Consoante final — sem acrescentar um “i” depois: stripe /stɹaɪp/, scope /skəʊp/, swift /swɪft/, persistent /pəˈsɪstənt/, consistent /kənˈsɪs.tənt/
/l/ final — a língua toca o céu da boca, não vira “u”: functional /ˈfʌŋkt͡ʃənəl/, virtual /ˈvɜɹt͡ʃuəl/, partial /ˈpɑɹʃəl/, enable /ɪˈneɪ.bəl/, eagle /ˈiːɡəl/
/h/ — um sopro suave, diferente do “r”: header /ˈhɛdɚ/, behalf /bɪˈhæf/, whoever /huˈɛvɚ/, whereas /(h)wɛɹˈæz/, hire /ˈhaɪɹ/

Como praticar com este vídeo

Ouça o vídeo inteiro uma vez sem falar e anote as palavras que você não conhece.
Comece na velocidade 0,75×, faça shadowing frase por frase e volte à velocidade normal quando ficar fácil.
Grave a sua voz e compare com o original, prestando atenção a palavras como database, functional, query.

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: System Design Interview: Design Ticketmaster w/ a Ex-Meta Staff Engineer - Aprenda a falar inglês com vídeo

Escolha um modo de prática

Baixar aplicativo

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

Proximity Search & Geospatial Indexes Explained

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

Redis Deep Dive w/ a Ex-Meta Senior Manager

Recommendation System Infra Basics 1

Consistent Hashing: Easy Explanation for System Design Interviews

Distributed Task Scheduler: System Design Interview (Stripe & Amazon Offers)

Uber Data Engineering Mock Interview - Ride-Sharing Data Warehouse Schema

How to Answer System Design Interview Questions (Complete Guide)

Google product manager behavioral interview (Top 5 questions)

Is AI Killing Human Fashion Design? Who Will Shape the Future of Design? Fashion Tea #6

Mastering iOS Development: Mock Interview with Ramiro Neto

[2026] TOEFL iBT Speaking Take an Interview | Step-by-Step Strategies #0008

My Senior UX Design Interview Experience | tips, questions, prep, & more!

Solving Easy SQL Interview Questions on Analyst Builder

2025 DevOps, SRE, Cloud Engineer Interview Questions: Ace Your Interview with This Guide

Vocabulário e dicas de fala para esta lição

Vocabulário principal deste vídeo

Phrasal verbs que você vai ouvir

Frases que vale a pena repetir

Gramática neste vídeo

Pronúncia para ficar de olho

Como praticar com este vídeo

O que é a Técnica de Shadowing?