-: So we'll need a customer table 2 2
and a restaurant table for sure. 3 3
We'll need to tie them together. 4 4
So each customer and restaurant 5 5
will need some unique ID associated with them. 6 6
So what might we need to know about a customer? 7 7
Certainly their name, their contact info, 8 8
maybe some information to help them find their favorite 9 9
restaurants or restaurants that are close to them. 10 10
So we'll need their location as well. 11 11
Maybe a list of their preferences, 12 12
like their favorite restaurants, 13 13
and we'll also need to store their login credentials, 14 14
but this would probably be stored in a more secure system 15 15
or using some single sign on system and not here. 16 16
Now for the restaurant, we also need its name, 17 17
address, and contact info. 18 18
We also need to know its layout so we can match up 19 19
reservation requests to available tables. 20 20
The application we build will have to have some fairly 21 21
complex logic for assigning reservations to tables, 22 22
maybe even taking to account the possibility of moving 23 23
tables together to accommodate large groups. 24 24
We also need to make some assumptions about how long 25 25
it takes for a dining party to finish their meal 26 26
and to clear the table for the next reservation. 27 27
So that's something the restaurant 28 28
will probably have to have some control over 29 29
the length of time that a reservations lasts. 30 30
Maybe that ends up being a function 31 31
of the party size as well, or the time of day 32 32
we'd have to interview some real restaurant owners 33 33
to understand how to best model that. 34 34
I assume they'll also want to keep some tables aside 35 35
to have a walk-in customer so we should at least 36 36
let the restaurant specified how much capacity 37 37
they want to hold back for walk-ins. 38 38
-: That's great, you're really thinking 39 39
of the customers here and what they'll need. 40 40
-: Okay, so finally, we'll need a reservation table 41 41
that ties it all together. 42 42
The app will have to use its own logic 43 43
to assign reservation requests 44 44
for a given customer, restaurant in time. 45 45
So somewhere we'll have a table of reservations 46 46
partitioned by restaurant ID's so we can quickly look up 47 47
reservations for a given restaurant. 48 48
I imagine we'd further partitioned by date 49 49
to make it quick to look up existing reservations 50 50
for a given date at a given restaurant, 51 51
which the algorithm will need to try and find an opening. 52 52
-: Mm hmm, great that you're thinking about 53 53
how the data is stored for optimal performance. 54 54
So is there a reason you're going with a normalized data 55 55
representation instead of a de-normalized one? 56 56
-: Right. Well, thinking about the operations 57 57
we'll likely need to do let's see 58 58
you'll probably already have the customer ID 59 59
and restaurant ID on the client. 60 60
By the time you navigate to the point where you want 61 61
to create a new reservation, right? 62 62
So I think it's simpler to just retrieve the information 63 63
on restaurants and clients as needed by their own hits to 64 64
the database, or maybe in the cash in front of the database. 65 65
That way we don't waste any space. 66 66
And we don't have to deal with the problem of updating 67 67
everything in some huge de-normalized table. 68 68
Every time a customer changes 69 69
their phone number or something. 70 70
Now, if, while testing, we find that there is 71 71
some complex joint operation going on, 72 72
that we're doing over and over again, 73 73
and it's a huge performance bottleneck. 74 74
Well, we could revisit that then, 75 75
but my instinct here is to start simple 76 76
and only add the complexity of de-normalization 77 77
if it's needed later on. 78 78
-: Mm hmm, makes sense to me. 79 79
Okay, keep going. 80 80
-: All right so what information 81 81
is associated with a reservation? 82 82
Obviously the customer and the restaurant it is for, 83 83
the party size and the time. 84 84
We might also want a space for notes to the restaurant, 85 85
like any special occasions or dietary restrictions 86 86
that they might want to know ahead of time. 87 87
-: Okay, that's good. 88 88
Let's move on to designing a larger system here. 89 89
-: Okay. So I think the design is pretty straightforward. 90 90
We have a bunch of clients that represent our diners 91 91
and they're running an app or something that needs to issue 92 92
service requests over HTTP somehow over the internet. 93 93
Now, since we can have a large number of diners, 94 94
we need to horizontally scale the servers 95 95
that process these requests, 96 96
the act of placing a reservation or retrieving information 97 97
about a diner or a restaurant seems atomic and stateless. 98 98
So that shouldn't really pose a problem here. 99 99
We just have APIs for requesting a reservation 100 100
and retrieving metadata to display 101 101
about users and restaurants. 102 102
There also needs to be some API for securely logging in, 103 103
creating an account and stuff like that. 104 104
But let's assume we're using some secure 105 105
external system for user management 106 106
which is outside of what we're building. 107 107
Ideally these servers will be hosted across different racks, 108 108
data centers and regions and geo routed whenever possible, 109 109
that would maximize availability. 110 110
Assuming that we build in sufficient capacity 111 111
to handle the outage of an entire region. 112 112
And I'm gonna draw a big hand-wavy 113 113
big NoSQL database here that stores our customers, 114 114
restaurants and reservations tables. 115 115
The application logic for assigning reservations 116 116
to time slots will live in the servers 117 117
that talk to this database. 118 118
And although I'm drawing it as a single giant bottleneck, 119 119
this is really some horizontally scale database system 120 120
to ensure it can handle high loads and high availability. 121 121
We'll probably also want to send text messages to people 122 122
reminding them of their reservations. 123 123
So we'll have some application server off on the side, 124 124
querying the same database 125 125
and firing off SMS messages as appropriate. 126 126
I'm drawing this as a single server 127 127
as that probably would be sufficient, 128 128
but of course we'd have some sort 129 129
of a fail over set up on that as well. 130 130
Maybe just with a cold standby, ready to go. 131 131
This seems like sort of a nice to have feature, 132 132
but if it is deemed critical, 133 133
we could also put it behind a low balancer just to ensure 134 134
that we have redundancy all at the time. 135 135
-: I mean, is there really any reason not to do that? 136 136
-: No, I suppose not so let's imagine another load balancer 137 137
and at least a couple of servers 138 138
in different data centers handling the SMS part. 139 139
-: Tell me more about your big hand-wavy NoSQL database. 140 140
How would you go about choosing 141 141
a specific technology for that? 142 142
-: Well, part of it would come down to what tools 143 143
your staff is already familiar with. 144 144
If you're an AWS shop, then I would think DynamoDB 145 145
would fit the bill nicely. 146 146
But let's think about the CAP theorem. 147 147
You said earlier, we care about availability and speed. 148 148
So that implies partition tolerance. 149 149
So that means we can maybe give up a little bit on 150 150
consistency. 151 151
So, something like Cassandra that has eventual consistency 152 152
in exchange for not having a single master server 153 153
might be a reasonable choice. 154 154
But I think I would push back on those requirements. 155 155
Consistency probably is important for this application. 156 156
It just isn't something we talked about yet. 157 157
We definitely don't want two customers 158 158
ending up with the same reservation slot. 159 159
I mean, in practice, even the databases that trade off 160 160
availability are still highly available. 161 161
If you throw enough secondary servers 162 162
and backup master servers at them. 163 163
So the usual suspects like MongoDB or DynamoDB 164 164
or its equivalent in Google cloud, 165 165
or Azure is probably a fine choice. 166 166
-: Yeah, that's good. 167 167
Business owners don't always think about these things. 168 168
And part of your job is to help them think about these sorts 169 169
of requirements and the trade-offs involved. 170 170
Now, the data you sketched out earlier 171 171
is relational in nature. 172 172
We've got customers and restaurants 173 173
referenced in each reservation. 174 174
Do we need a traditional relational database 175 175
like Oracle or MySQL to handle that? 176 176
-: No, the application servers can query 177 177
the individual tables and join them internally as needed. 178 178
We're not doing anything complicated where that would be a 179 179
real key performance concern or anything like that. 180 180
A modern distributed databases 181 181
can just do the join for us efficiently on their own anyhow. 182 182
So let's go with NoSQL meaning not only SQL. 183 183
-: Okay. 184 184
We have just a few minutes left before I have to move on. 185 185
One last question, what about caching? 186 186
Do we need it? 187 187
How can we further improve the performance of the system? 188 188
-: Well, we don't really have a lot of static content 189 189
in this system, so something like a CDN 190 190
probably wouldn't do a whole lot of good 191 191
if the client applications or just web pages though, 192 192
we'd probably want a CDN for a fast hosting of the CSS 193 193
and JavaScript and images needed on the client side. 194 194
We talked about hosting the app servers 195 195
across different regions in geo routing to them. 196 196
So at least that will cut down on some latency. 197 197
We probably would want to have some sort of a cache 198 198
for the database queries though. 199 199
So the customer and restaurant data 200 200
isn't likely to change very often. 201 201
So certainly that can be cashed. 202 202
So let's assume we have something like Memcached or Redis 203 203
sitting on top of those queries inside the app servers. 204 204
Maybe Memcached because it's simpler 205 205
and we don't really need anything fancy here. 206 206
That gives us a little bit more flexibility 207 207
in how the database is distributed across regions as well. 208 208
It doesn't really do much good to geo route to servers. 209 209
If those servers all have to talk 210 210
to one region for the data. 211 211
-: Well, obviously there is a lot more to talk about 212 212
if we were to build this for real, 213 213
but you hit on all the main concerns. 214 214
So let's move on.