1
00:00:00,300 --> 00:00:04,000
One thing I've realized in the 
past, probably 15 years, is this

2
00:00:04,000 --> 00:00:08,700
whole notion of transaction and 
consistency and acid compliance 

3
00:00:08,700 --> 00:00:14,300
and all that stuff is many a 
times, a composed, as in all the

4
00:00:14,300 --> 00:00:16,500
business wants is don't lose my 
transaction. 

5
00:00:16,500 --> 00:00:19,700
They don't really care if it's 
like acid compliant, or this all

6
00:00:19,708 --> 00:00:22,700
that, right? 
And we as technologists should 

7
00:00:22,700 --> 00:00:25,200
not make choices. 
It's the business that you make 

8
00:00:25,200 --> 00:00:31,600
that decision. 
Hey everyone. 

9
00:00:32,100 --> 00:00:36,900
My name is Henry Surya Vaughn. 
And you're listening to the 

10
00:00:36,900 --> 00:00:40,100
technology, you know, podcast 
the show where I'll be bringing 

11
00:00:40,100 --> 00:00:43,300
you the greatest technical 
leaders practitioners and 

12
00:00:43,300 --> 00:00:47,000
thought leaders in the industry 
to discuss about their Journey 

13
00:00:47,300 --> 00:00:51,700
ideas and practices that we all 
can learn and apply to build a 

14
00:00:51,708 --> 00:00:55,300
highly performing technical team
and to make an impact in your 

15
00:00:55,300 --> 00:00:58,500
personal work. 
So let's dive into our Journal. 

16
00:01:03,600 --> 00:01:05,900
Hey again everyone welcome to 
the technology. 

17
00:01:05,900 --> 00:01:08,800
Now podcast the podcast where 
you can learn about technical 

18
00:01:08,800 --> 00:01:11,700
leadership and Excellence from 
my conversations, with great 

19
00:01:11,700 --> 00:01:13,400
thought, leaders in the tech 
industry. 

20
00:01:13,800 --> 00:01:15,900
If this is your first time 
listening to this show, 

21
00:01:15,900 --> 00:01:18,800
subscribe and follow the show on
your podcast app and social 

22
00:01:18,800 --> 00:01:21,100
media on LinkedIn, Twitter and 
Instagram. 

23
00:01:21,400 --> 00:01:24,300
And for those of you longtime 
listeners who want to appreciate

24
00:01:24,300 --> 00:01:27,500
and support my work, subscribe 
as a patron at technology. 

25
00:01:27,500 --> 00:01:30,700
No dot f /. 
On or buy me a coffee at 

26
00:01:30,700 --> 00:01:32,700
technology node. 
Dev slash tip. 

27
00:01:33,500 --> 00:01:36,000
My guest for today's episode is 
promotes Adel. 

28
00:01:36,000 --> 00:01:39,600
GA promote is a director 
thoughtworks and the quarter of 

29
00:01:39,600 --> 00:01:42,800
several data and architecture 
books such as software 

30
00:01:42,800 --> 00:01:45,800
architecture, the hard parts and
the jolt award-winning 

31
00:01:45,800 --> 00:01:49,700
refactoring databases. 
In this episode, we discussed 

32
00:01:49,700 --> 00:01:51,800
data Essentials. 
In software architecture, 

33
00:01:52,200 --> 00:01:55,600
promote started by explaining 
why dealing with data is hard in

34
00:01:55,600 --> 00:01:58,900
software architecture, and some 
data related concerns, we should

35
00:01:59,100 --> 00:02:02,200
Think about when making 
architecture decisions, he then 

36
00:02:02,200 --> 00:02:04,800
shared the thought process of 
how we can choose the right 

37
00:02:04,800 --> 00:02:08,300
database for our purpose and 
shared insights on data 

38
00:02:08,300 --> 00:02:11,200
modeling, differences, between 
SQL and nosql. 

39
00:02:11,700 --> 00:02:14,500
Promote also touch on the 
important considerations in 

40
00:02:14,500 --> 00:02:17,900
managing transactions, and the 
trade-offs between acid and 

41
00:02:17,900 --> 00:02:22,000
eventual consistency towards the
end, promote shared practical 

42
00:02:22,000 --> 00:02:25,300
advice on the step by step, how 
we can split a monolithic 

43
00:02:25,300 --> 00:02:27,600
database through database 
refactoring. 

44
00:02:28,200 --> 00:02:31,200
This is such a Great discussion 
with promote to discuss, all 

45
00:02:31,200 --> 00:02:35,000
things about data and databases 
and I hope you enjoy it as much 

46
00:02:35,000 --> 00:02:37,000
as I do. 
And if you do, I would 

47
00:02:37,000 --> 00:02:39,000
appreciate it. 
If you can help, share this 

48
00:02:39,000 --> 00:02:41,400
episode with your colleagues 
friends communities. 

49
00:02:41,600 --> 00:02:44,200
So that more people would also 
be able to learn from this 

50
00:02:44,200 --> 00:02:46,500
episode. 
Please also leave a five star 

51
00:02:46,500 --> 00:02:50,500
rating and review on a podcast 
and Spotify which I will highly 

52
00:02:50,500 --> 00:02:53,100
appreciate. 
Let's go to my conversation with

53
00:02:53,100 --> 00:02:55,700
promote after a few words from 
our sponsors. 

54
00:02:56,300 --> 00:02:58,300
Are you looking for a new cool 
swag? 

55
00:02:58,600 --> 00:03:01,400
Tackle it You know now offers 
you some swags that you can 

56
00:03:01,400 --> 00:03:05,700
purchase online, these wax are 
printed on demand based on your 

57
00:03:05,700 --> 00:03:09,400
preference and will be delivered
safely to you all over the world

58
00:03:09,400 --> 00:03:12,700
where shipping is available. 
Check out all the cool tracks 

59
00:03:12,700 --> 00:03:16,200
available by visiting 
technology, no, dot f / shop, 

60
00:03:16,300 --> 00:03:17,900
and don't forget to break 
yourself. 

61
00:03:18,000 --> 00:03:20,100
Once you receive any of those 
tracks. 

62
00:03:22,900 --> 00:03:24,600
Hey everyone. 
Welcome back to another new 

63
00:03:24,600 --> 00:03:27,100
episode of the technology on our
podcast today. 

64
00:03:27,100 --> 00:03:30,800
I have with me consultant at 
Bollocks, he has been there for 

65
00:03:30,800 --> 00:03:34,500
25 years, that's pretty long. 
And in my view, his name is 

66
00:03:34,500 --> 00:03:38,100
promotes Adele, gay is actually 
someone who is very experienced 

67
00:03:38,100 --> 00:03:42,000
in dealing with data databases 
the intersection between data 

68
00:03:42,000 --> 00:03:45,200
and applications. 
He's also the well-known author 

69
00:03:45,300 --> 00:03:48,700
of this book called refactoring 
databases, even though it has 

70
00:03:48,700 --> 00:03:51,700
been written long time ago, I 
think it's still applicable and 

71
00:03:51,700 --> 00:03:54,900
relevant these days whenever you
want to deal with rdbms and how 

72
00:03:54,900 --> 00:03:58,400
to make changes and evolution 
towards your schema. 

73
00:03:59,100 --> 00:04:03,100
So the cost of nosql distill 
recipes for continuous database,

74
00:04:03,100 --> 00:04:05,600
integration software 
architecture, the hard parts and

75
00:04:05,600 --> 00:04:08,100
the recent book evolutionary 
architecture, which is the 

76
00:04:08,100 --> 00:04:10,800
second edition. 
So promote, welcome to the show.

77
00:04:10,800 --> 00:04:13,600
Really looking forward for this 
conversation to talk a lot about

78
00:04:13,600 --> 00:04:16,899
database and data. 
Yeah, thank you. 

79
00:04:16,899 --> 00:04:20,500
And we data in databases have 
been my passion for almost 30 

80
00:04:20,500 --> 00:04:22,800
years. 
Now I'm happy to talk about 

81
00:04:23,600 --> 00:04:25,800
nice. 
So, promote in the beginning, I 

82
00:04:25,800 --> 00:04:28,600
always love to ask my guess to 
share a little bit more about 

83
00:04:28,600 --> 00:04:30,700
yourself. 
Our first, maybe you can share 

84
00:04:30,700 --> 00:04:33,400
some career Journey or any 
highlights turning points that 

85
00:04:33,400 --> 00:04:35,800
you feel are worth to share with
the audience here. 

86
00:04:36,400 --> 00:04:40,400
My journey started back when I 
was in 7th grade computers, or 

87
00:04:40,400 --> 00:04:43,800
spoon, had these two computers 
for Des Moines school, and you 

88
00:04:43,800 --> 00:04:46,400
can go play with them. 
And you sounds, I need a little 

89
00:04:46,400 --> 00:04:55,000
bit of basic games and computers
all through high school. 

90
00:04:56,100 --> 00:05:01,100
I got into computer engineering.
We call it a finish that and 

91
00:05:01,100 --> 00:05:03,200
during that time that is 
amazing. 

92
00:05:03,200 --> 00:05:07,800
Professor cordac examines each 
worker and he really inspired 

93
00:05:08,400 --> 00:05:12,100
how to think about operating 
systems or distributor. 

94
00:05:13,800 --> 00:05:15,300
So, I did a project on this 
team. 

95
00:05:16,200 --> 00:05:20,300
What is the most efficient way 
to distribute work on cluster of

96
00:05:20,300 --> 00:05:22,600
computers? 
It's really interesting. 

97
00:05:23,700 --> 00:05:27,800
And then after that job hunting 
stuff and ultimately ended up in

98
00:05:28,000 --> 00:05:33,100
quotes around 99, your four 
years in the middle, different 

99
00:05:33,100 --> 00:05:35,600
places. 
And we were doing this Amazing 

100
00:05:35,600 --> 00:05:41,100
Project called a class where we 
had an existing database that 

101
00:05:41,100 --> 00:05:44,700
was being worked on big upfront 
design kind of database that was

102
00:05:44,700 --> 00:05:46,700
already designed 600 plus 
tables. 

103
00:05:47,400 --> 00:05:52,500
And then this whole notion of 
Isaiah 60 Blake was Catching 

104
00:05:52,500 --> 00:05:55,200
Fire. 
And Martin Fowler, Edward 

105
00:05:55,200 --> 00:06:00,600
curling up giving coaches and 
coaching sessions per period of 

106
00:06:00,600 --> 00:06:05,000
time where so mind, changing 
that you would think, why was I 

107
00:06:05,000 --> 00:06:07,200
doing up for Designing? 
The first place ever? 

108
00:06:07,300 --> 00:06:09,700
Like why did I even do that? 
Right? 

109
00:06:10,100 --> 00:06:12,900
So we had this first iteration 
planning and we said, oh, we'll 

110
00:06:12,900 --> 00:06:14,600
do this much first, happy 
whatever. 

111
00:06:15,000 --> 00:06:18,400
And I went back to my test and 
build it on the people's that's 

112
00:06:18,400 --> 00:06:22,800
posting a day and that's a scary
thought for A person, but I did 

113
00:06:22,800 --> 00:06:26,300
and every iteration as planned, 
new stuff, you do new 

114
00:06:26,300 --> 00:06:29,700
functionality, you back things. 
You've got things to the table 

115
00:06:29,700 --> 00:06:34,600
and stuff are more stable, snow 
bunch of that constant change 

116
00:06:35,200 --> 00:06:38,600
and there are about 30 or so 
developers in that team plus 

117
00:06:38,600 --> 00:06:42,900
plus terms plus b, a is plus a 
bunch of other people and I was 

118
00:06:42,900 --> 00:06:45,500
the only divorce. 
So anything that came to the you

119
00:06:45,508 --> 00:06:50,000
do this, I literally walked into
their space discuss with them 

120
00:06:50,700 --> 00:06:51,700
the chain. 
With them. 

121
00:06:52,100 --> 00:06:55,100
And then I came up with this 
scheme of pregnancy, Henri meets

122
00:06:55,100 --> 00:06:58,200
a change. 
How do the rest of the 30 people

123
00:06:58,200 --> 00:07:01,700
that teach because by that time 
I had come up with this concept 

124
00:07:01,700 --> 00:07:04,900
of every question, working on 
the code base should have their 

125
00:07:04,900 --> 00:07:08,100
own schema they shouldn't be 
like shit excuse, right? 

126
00:07:08,400 --> 00:07:11,100
Because early in the beginning 
and I noticed that if they're 

127
00:07:11,100 --> 00:07:15,700
sharing schemas and I make a 
change for Henry John here, mix 

128
00:07:15,700 --> 00:07:18,300
affected because the see my 
history not quite okay. 

129
00:07:19,000 --> 00:07:20,600
So I said, okay, let's play 
everyone. 

130
00:07:20,700 --> 00:07:23,500
Schemas I came up with like a 
bunch of scripts. 

131
00:07:23,700 --> 00:07:26,700
They can create their own 
schemas, they can create their 

132
00:07:26,700 --> 00:07:30,600
own, like popular, that schema, 
and all kinds of, but a bad 

133
00:07:30,600 --> 00:07:34,400
script, I wouldn't call them 
devops, but a bunch of bats 

134
00:07:34,400 --> 00:07:37,700
grips on Windows machines that 
you could run like, create my 

135
00:07:37,700 --> 00:07:40,500
schema do that and it would 
create a scheme of Iran. 

136
00:07:42,100 --> 00:07:45,100
And once they happen and then we
came up with this concept of all

137
00:07:45,100 --> 00:07:48,500
I want to modify or splits, I 
would speed with them and come 

138
00:07:48,500 --> 00:07:51,800
up with a neat and then at some 
point of time, it so happened 

139
00:07:51,800 --> 00:07:54,900
that this is all going good but 
now we are trying to figure out 

140
00:07:54,900 --> 00:07:59,700
okay, how do I give away all the
power and simplicity and work 

141
00:07:59,700 --> 00:08:03,200
was last particular, slide? 
What are the discs between the 

142
00:08:03,200 --> 00:08:05,100
requirement? 
So that's where the whole 

143
00:08:05,100 --> 00:08:09,100
concept of version controlled 
migrations in Nevada. 

144
00:08:09,100 --> 00:08:14,600
So we didn't really have a 
number The thing is all these 

145
00:08:14,900 --> 00:08:17,700
things. 
I just keep track of each one 

146
00:08:17,700 --> 00:08:21,800
teach to tease myself and I kept
applying them and I knew what to

147
00:08:21,800 --> 00:08:25,800
use like an attractive tracking 
metadata, in those schemas in 

148
00:08:25,800 --> 00:08:29,600
what's amazed at what level 
bunch of that kind of stuff and 

149
00:08:29,600 --> 00:08:33,200
then ultimately, we figured out 
progression of changes. 

150
00:08:34,500 --> 00:08:38,000
And so when you are either in of
the New Path somewhere, like you

151
00:08:38,000 --> 00:08:40,299
encounter a bunch of problems as
we go, right? 

152
00:08:40,500 --> 00:08:43,799
And then Just trying to like, 
find out solutions to those 

153
00:08:43,799 --> 00:08:46,900
problems. 
One problem was, how do I know 

154
00:08:46,900 --> 00:08:49,400
what TJ was with this? 
Big was big? 

155
00:08:50,500 --> 00:08:53,400
So then we started publishing, 
what was the last chain that was

156
00:08:53,700 --> 00:08:57,500
available when this bill was. 
And we took that put it as a tie

157
00:08:57,500 --> 00:09:00,100
in the Village, self-published 
Package. 

158
00:09:00,600 --> 00:09:03,000
So who are unpacked the build 
new? 

159
00:09:03,000 --> 00:09:05,500
What change was needed for that 
to work? 

160
00:09:05,900 --> 00:09:08,800
So, once you have that small 
stuff like that, if you really 

161
00:09:08,800 --> 00:09:11,600
think out there was all of them 
with inconsequential, Initial 

162
00:09:12,200 --> 00:09:15,700
selection of them was really a 
say-so, not some of those 10 

163
00:09:15,700 --> 00:09:17,600
stars and my opinion at some 
want. 

164
00:09:17,600 --> 00:09:19,600
Look at the whole scheme, I had 
set up. 

165
00:09:19,700 --> 00:09:21,900
And so, this is a really 
interesting from was like, you 

166
00:09:21,900 --> 00:09:24,900
should speak about this talking 
about this, let other people 

167
00:09:24,900 --> 00:09:28,300
know about it. 
And so he took me to Madison 

168
00:09:28,300 --> 00:09:31,500
Java user group and they were 
like 600 people in the big 

169
00:09:31,500 --> 00:09:34,600
article in there. 
Everyone's had come mrs. 

170
00:09:34,600 --> 00:09:37,600
Martin, not me. 
But Marty put me in front of 

171
00:09:37,600 --> 00:09:39,500
Music. 
Some people for the first time 

172
00:09:39,500 --> 00:09:41,500
and I was shaking, you know. 
Up. 

173
00:09:42,200 --> 00:09:45,400
But I did give that talk and I 
sense like that was a good way 

174
00:09:45,400 --> 00:09:49,500
to share knowledge, like you 
learn something better to share 

175
00:09:49,500 --> 00:09:51,200
instead of this, keeping it 
yourself. 

176
00:09:51,700 --> 00:09:55,000
So I sat in sharing and then 
from there on, like lots of 

177
00:09:55,000 --> 00:09:58,500
other cops, I think speak on 
said, XD day is different 

178
00:09:58,500 --> 00:10:01,200
places. 
And I refined based on 

179
00:10:01,200 --> 00:10:03,700
questions, like, in your 
project, there's a certain 

180
00:10:03,700 --> 00:10:06,600
context. 
And once you've solved, all that

181
00:10:06,600 --> 00:10:09,400
context, there are no more new 
problems to solve. 

182
00:10:09,700 --> 00:10:13,800
So when we go out, People 
conference stocks generally 

183
00:10:13,800 --> 00:10:16,100
speak to people. 
You hear different contexts, 

184
00:10:16,100 --> 00:10:17,900
right? 
And then you want to learn how 

185
00:10:17,900 --> 00:10:19,900
to solve those make branching 
and merging. 

186
00:10:19,900 --> 00:10:22,600
We will do Braxton. 
Because at that time we always 

187
00:10:22,600 --> 00:10:24,800
did trunk waist up, but some 
people did. 

188
00:10:25,100 --> 00:10:29,400
And like, how do you manage team
says when you grunting really 

189
00:10:29,400 --> 00:10:32,600
interesting stuff like that. 
So ultimately, I think around 

190
00:10:32,600 --> 00:10:36,600
2004 or something additional, 
Martin came up with this idea of

191
00:10:36,600 --> 00:10:39,800
whatever I was doing at similar 
stuff, was also being done by 

192
00:10:39,800 --> 00:10:43,100
Scott Ambler. 
Basically put both together and 

193
00:10:43,100 --> 00:10:47,000
say quality the refactoring 
database is evolutionary 

194
00:10:47,000 --> 00:10:50,800
database design book. 
So we then took all the changes 

195
00:10:50,800 --> 00:10:55,500
that I was doing on projects, 
like move columns, column table,

196
00:10:55,800 --> 00:10:59,500
to table and codified them and 
came up with the structure that 

197
00:10:59,600 --> 00:11:01,400
just like how Martin's 
refactoring book. 

198
00:11:01,400 --> 00:11:05,500
Say if you tell Annie - black 
method, if someone says that, 

199
00:11:05,500 --> 00:11:11,900
you know exactly what so our 
language or naming. 1/2, a bunch

200
00:11:11,900 --> 00:11:14,800
of things that would happen, so 
something similar to that. 

201
00:11:15,100 --> 00:11:18,900
So, by the time IntelliJ had 
shortcut keys to expect method 

202
00:11:18,900 --> 00:11:21,500
and a bunch of that kind of 
stuff, we are inspired by that. 

203
00:11:21,500 --> 00:11:25,400
So we came up with that name 
came out over 70 or so patterns 

204
00:11:25,500 --> 00:11:28,900
that we put in the book and we 
talked a lot about the book and 

205
00:11:28,900 --> 00:11:31,400
later on, I got about 13 years 
integration. 

206
00:11:31,400 --> 00:11:37,000
And so other 2008, I'm see this 
whole nosql movement was like 

207
00:11:37,000 --> 00:11:39,300
really finding out and lots of 
stuff. 

208
00:11:39,300 --> 00:11:42,700
Like we have look paper, come 
about Lots of people are doing 

209
00:11:42,700 --> 00:11:46,600
different things with a mongodb.
I think point five point eight 

210
00:11:46,700 --> 00:11:49,100
come out so I did a project with
mongodb. 

211
00:11:49,400 --> 00:11:52,600
We also need a project agree on 
and then I started talking 

212
00:11:52,600 --> 00:11:56,800
thinking about the value 
designed objects in object 

213
00:11:56,800 --> 00:12:00,300
oriented languages and how you 
store them in relational 

214
00:12:00,300 --> 00:12:02,800
databases, a translation that 
needs to happen. 

215
00:12:03,500 --> 00:12:06,900
It's not the same with no 
escalator, right? 

216
00:12:06,900 --> 00:12:10,000
Like object-oriented stuff. 
How does it translate to 

217
00:12:10,000 --> 00:12:11,100
document? 
How does it? 

218
00:12:11,200 --> 00:12:14,300
A spare, key value stores. 
How does it pass the columns or 

219
00:12:14,700 --> 00:12:16,400
how does it translate to graph 
stores? 

220
00:12:16,900 --> 00:12:20,700
So that gave me an idea of we 
should probably talk about how 

221
00:12:20,700 --> 00:12:24,000
this modeling works and why you 
choose one over the other. 

222
00:12:24,200 --> 00:12:27,200
I like to talk about this 
concept of like, an automatic 

223
00:12:27,200 --> 00:12:30,000
car like gears, like you put in 
dries and you just try it. 

224
00:12:30,008 --> 00:12:32,300
You don't worry about what's 
underneath, right? 

225
00:12:32,500 --> 00:12:36,900
Worry about first gear, second 
gear, this and that like, 

226
00:12:36,900 --> 00:12:40,000
automobile reference here, 
that's what relational databases

227
00:12:40,000 --> 00:12:43,000
where they picked. 
See or anything else, they 

228
00:12:43,000 --> 00:12:46,100
picked a bunch of that kind of 
stuff for you and you don't have

229
00:12:46,100 --> 00:12:50,200
to worry about anything else. 
So by default, you get those 

230
00:12:50,200 --> 00:12:52,800
things and developers don't have
to worry about other choices 

231
00:12:53,000 --> 00:12:55,300
because there was no choice. 
But once you go to another 

232
00:12:55,300 --> 00:12:58,400
escalator basis, there's a lot 
of choice. 

233
00:12:58,400 --> 00:13:01,400
So you have to decide what is 
the choice that you want? 

234
00:13:01,500 --> 00:13:04,300
Because you can just go blindly 
saying, I don't care what choice

235
00:13:04,900 --> 00:13:08,500
once you go into that the 
availability of choices creates 

236
00:13:08,500 --> 00:13:11,300
lots of options. 
And at the same time also, So 

237
00:13:11,300 --> 00:13:14,300
creates lots of pitfalls with 
what if you make the wrong 

238
00:13:14,300 --> 00:13:16,700
choice. 
So that's why we thought about 

239
00:13:16,700 --> 00:13:19,400
writing that book, The nosql 
distilled Utah. 

240
00:13:19,400 --> 00:13:22,900
This is a broad survey of what 
types of nosql databases are 

241
00:13:22,900 --> 00:13:26,400
there, how we pick them? 
What is consistency? 

242
00:13:26,400 --> 00:13:30,800
The Gap here on distribution, 
mapreduce bunch of, that kind of

243
00:13:30,800 --> 00:13:35,000
stuff, all together. 
And how we should dispel people 

244
00:13:35,000 --> 00:13:37,200
from like, oh no skill 
schema-less. 

245
00:13:37,200 --> 00:13:38,700
So, I don't have to worry about 
schema. 

246
00:13:39,400 --> 00:13:41,000
That's not true. 
The schema is there. 

247
00:13:41,200 --> 00:13:43,900
A code it's not in the database 
but it is still there in your 

248
00:13:43,900 --> 00:13:47,000
courts. 
We have to crack of it and stuff

249
00:13:47,000 --> 00:13:48,800
and how you shouldn't have to be
like these. 

250
00:13:48,800 --> 00:13:50,500
It's equal. 
Or is it nosql? 

251
00:13:50,500 --> 00:13:53,100
It's not that. 
It's just like with in the same 

252
00:13:53,100 --> 00:13:56,200
Enterprise or within the same 
system you could be having more 

253
00:13:56,200 --> 00:13:58,300
than one. 
And that's where the polyglot 

254
00:13:58,300 --> 00:14:01,600
word came about is you could 
have more than one type of 

255
00:14:01,600 --> 00:14:05,800
storage and we give like couple 
of examples and so that was 

256
00:14:05,800 --> 00:14:08,100
pretty good. 
And then later on, I wrote 

257
00:14:08,100 --> 00:14:10,800
something with Neil around 
software architecture, the hard 

258
00:14:10,800 --> 00:14:12,600
part. 
It's about how do you pick? 

259
00:14:12,600 --> 00:14:16,100
Because I personally think many 
times the data people are 

260
00:14:16,100 --> 00:14:19,800
excluded from architecture 
discussion and it may be by 

261
00:14:19,800 --> 00:14:23,300
choice or it may be like a like 
once we decide the architecture 

262
00:14:23,300 --> 00:14:27,000
we can just store data somewhere
and I think that's a misnomer or

263
00:14:27,000 --> 00:14:30,000
you should be including data 
Architects, people who be with 

264
00:14:30,000 --> 00:14:34,500
data into the architectural 
decisions because long-term 

265
00:14:34,500 --> 00:14:37,900
where data is stored, how it's 
stored, affects a lot of 

266
00:14:37,900 --> 00:14:40,700
different things. 
Ultimately all business really 

267
00:14:40,700 --> 00:14:43,800
wants to He's not your code but 
bait, right? 

268
00:14:44,100 --> 00:14:48,500
Because business runs our data 
data is, what is stored persists

269
00:14:48,500 --> 00:14:49,800
applications? 
Come in go. 

270
00:14:50,300 --> 00:14:55,100
So how to like, make sure your 
data is available, find about 

271
00:14:55,300 --> 00:14:58,500
interoperable. 
Like this are principles, how 

272
00:14:58,500 --> 00:15:00,800
can they be applied? 
And all that kind of stuff. 

273
00:15:01,300 --> 00:15:04,300
So, inclusion of the data 
protects in this whole, 

274
00:15:04,300 --> 00:15:07,500
Enterprise architecture, 
architectural generating, should

275
00:15:07,500 --> 00:15:10,600
be encouraged and even data 
architect should be saying, I 

276
00:15:10,600 --> 00:15:12,500
want to be Be there in that 
discussion. 

277
00:15:13,000 --> 00:15:15,300
Yeah, so that's my journey. 
I've been here. 

278
00:15:15,300 --> 00:15:18,300
I've got books for almost 25 
years and still enjoying it. 

279
00:15:18,400 --> 00:15:21,600
And right now, I'm doing a bunch
of stuff around data mesh type 

280
00:15:21,600 --> 00:15:24,500
of architectures and 
implementations of that idea. 

281
00:15:25,300 --> 00:15:27,000
Well, thanks for sharing. 
Your story is really 

282
00:15:27,000 --> 00:15:29,400
interesting. 
How you got this, all started 

283
00:15:29,400 --> 00:15:32,200
right surgery from refactoring, 
databases from project 

284
00:15:32,200 --> 00:15:35,200
experience, having to share it 
in front of the audience, for 

285
00:15:35,200 --> 00:15:37,900
that large amount of audience. 
I think that's pretty scary to 

286
00:15:37,900 --> 00:15:39,500
me, as well in the beginning, I 
believe. 

287
00:15:39,900 --> 00:15:42,300
And I think since then, yeah, 
you Dealt with a lot of our data

288
00:15:42,300 --> 00:15:44,800
challenges and wrote A Few 
books, along the way. 

289
00:15:45,200 --> 00:15:48,200
So I had Neil a couple of 
episodes before talking about 

290
00:15:48,200 --> 00:15:49,800
software architecture, the hard 
part. 

291
00:15:49,900 --> 00:15:53,000
And I think with having you here
in this episode as well, I want 

292
00:15:53,000 --> 00:15:56,200
to continue our conversation 
about the architecture but 

293
00:15:56,200 --> 00:15:59,300
dealing with data I think, as we
all know, dealing with data is 

294
00:15:59,300 --> 00:16:01,500
very difficult. 
In fact, many people think it's 

295
00:16:01,500 --> 00:16:04,600
the most difficult thing because
your applications come and go 

296
00:16:04,600 --> 00:16:07,100
like what you said but the data 
always stays there. 

297
00:16:07,400 --> 00:16:09,900
So the first thing is probably 
if you can share with the 

298
00:16:09,900 --> 00:16:13,500
audience here, how much has that
changed these days with all the 

299
00:16:13,500 --> 00:16:16,800
advancement of technology? 
Different types of databases is 

300
00:16:16,800 --> 00:16:19,200
data still, the hard part of the
architecture. 

301
00:16:19,900 --> 00:16:23,700
The Ada is still hard because 
bunch of data is locked inside 

302
00:16:23,700 --> 00:16:26,900
commercial systems that are 
bought off the shelf, so bunch 

303
00:16:26,900 --> 00:16:30,500
of stuff, just sits there. 
And then how do we get it out? 

304
00:16:30,500 --> 00:16:32,000
So it's useful. 
Other parts of the 

305
00:16:32,000 --> 00:16:34,100
organization's is very 
important. 

306
00:16:34,400 --> 00:16:38,300
Many, a times data is also stuck
behind some kind of I would say 

307
00:16:38,300 --> 00:16:40,900
walls because oh it's available 
in that day only. 

308
00:16:41,200 --> 00:16:44,100
You can object to it or it's 
available there but you don't 

309
00:16:44,100 --> 00:16:46,500
have the right Keys. 
You don't have the right way to 

310
00:16:46,500 --> 00:16:51,200
get it out and stuff. 
So right more than the desire, I

311
00:16:51,208 --> 00:16:54,800
think the paths to get to the 
data physical and people are 

312
00:16:54,800 --> 00:16:57,100
working on that. 
And I think that's why betameche

313
00:16:57,100 --> 00:17:01,000
is become so popular is because 
it gives you like this domain 

314
00:17:01,000 --> 00:17:04,400
oriented weight that getting at 
data and you can deal with data 

315
00:17:04,400 --> 00:17:07,400
and piecemeal stuff, instead of 
oh, I need to build this whole 

316
00:17:07,400 --> 00:17:09,900
data warehouse before I get 
access to it. 

317
00:17:10,099 --> 00:17:12,500
Now, people are saying okay. 
Can we like talk about it in a 

318
00:17:12,500 --> 00:17:16,400
smaller chunks of pieces and 
time to Market has reduced 

319
00:17:16,400 --> 00:17:19,200
because of that, right? 
And that I think is making life 

320
00:17:19,200 --> 00:17:21,400
easier. 
There's also this notion 

321
00:17:21,400 --> 00:17:24,900
nowadays all Cloud providers 
give you some type of storage 

322
00:17:24,900 --> 00:17:28,300
mechanisms and those are also 
like all the way from like five 

323
00:17:28,300 --> 00:17:32,900
storage block storage, all the 
data analytics based storage and

324
00:17:32,900 --> 00:17:34,000
stuff. 
I mean, there's a bunch of 

325
00:17:34,000 --> 00:17:36,800
choice there. 
But as people are using Cloud 

326
00:17:36,800 --> 00:17:40,700
Technologies, interoperable of 
that data is become a little bit

327
00:17:40,700 --> 00:17:44,400
easier. 
And having access to that but we

328
00:17:44,400 --> 00:17:46,800
are still dealing with the 
problem of people decide to put 

329
00:17:46,800 --> 00:17:50,400
stuff all over the place and 
then knowing what did I store? 

330
00:17:50,400 --> 00:17:52,800
Where was it stored? 
What's the definition of that? 

331
00:17:53,000 --> 00:17:56,300
What's the meaning of that 
column, or table or whatever is 

332
00:17:56,300 --> 00:17:59,200
still harder, right? 
So we need to be a little bit 

333
00:17:59,200 --> 00:18:03,200
more disciplined and structured 
about how do I store stuff. 

334
00:18:03,200 --> 00:18:06,200
I mean, the basics of computer 
science is meaning things like 

335
00:18:06,200 --> 00:18:09,100
the name, your favor, right? 
Calibrate, all kinds of stuff. 

336
00:18:09,100 --> 00:18:11,900
Like, even if you have a Json to
do, you mean They sauntered 

337
00:18:11,900 --> 00:18:14,600
attributes, right? 
So once of that kind of stuff, 

338
00:18:14,600 --> 00:18:17,700
still needs to be followed 
religiously so that someone who 

339
00:18:17,700 --> 00:18:20,400
has not worked with, you can 
understand what that structure 

340
00:18:20,400 --> 00:18:22,700
is. 
Because again, we have so remote

341
00:18:22,700 --> 00:18:25,800
and select and or consists of in
someone waiting, looking at the 

342
00:18:25,808 --> 00:18:28,500
Json that you publish. 
And they may not even know 

343
00:18:28,500 --> 00:18:32,100
either that you exist, right? 
So how do they get what we 

344
00:18:32,100 --> 00:18:36,000
desire means without spending? 
A lot of Cycles, easy challenge,

345
00:18:36,700 --> 00:18:39,300
right? 
And specifically you also invite

346
00:18:39,300 --> 00:18:42,000
that like just now when you were
sharing, The beginning, right? 

347
00:18:42,000 --> 00:18:45,800
You invited people to include 
the data architects in the 

348
00:18:45,800 --> 00:18:48,700
beginning whenever people are 
talking or deciding about the 

349
00:18:48,708 --> 00:18:52,000
architecture so that they're 
involved, maybe specifically in 

350
00:18:52,000 --> 00:18:55,500
your experience, what would be 
some of the areas of concerns 

351
00:18:55,600 --> 00:18:59,200
for a bunch of Architects and 
data Architects to discuss about

352
00:18:59,200 --> 00:19:02,200
whenever they want to make 
decisions about data-related? 

353
00:19:02,700 --> 00:19:04,800
Yeah. 
So I think the first thing 

354
00:19:04,800 --> 00:19:08,600
probably higher level thing that
you should be thinking about is,

355
00:19:08,700 --> 00:19:11,200
what are the forums where beta 
people? 

356
00:19:11,300 --> 00:19:15,100
Should we invite and once I've 
had clients that we go at, I 

357
00:19:15,100 --> 00:19:17,000
tell them. 
Anyway away, this architect 

358
00:19:17,000 --> 00:19:18,700
involved, you should have a 
data. 

359
00:19:19,200 --> 00:19:23,500
Having said that the areas of 
concerns is generally you want 

360
00:19:23,500 --> 00:19:27,700
to give people enough freedom to
low-weight do things and that 

361
00:19:27,700 --> 00:19:30,200
kind of stuff. 
But at the same time it should 

362
00:19:30,200 --> 00:19:32,700
be such a blank canvas that they
do whatever they want. 

363
00:19:33,100 --> 00:19:37,400
So a good example of this is a 
CR, a specific Cloud usage and 

364
00:19:37,400 --> 00:19:39,100
of company. 
And someone says, hey, that 

365
00:19:39,100 --> 00:19:42,000
other Cloud gives me that 
feature and this will Use that. 

366
00:19:42,300 --> 00:19:45,700
So you should be having some 
guardrails saying, okay, you 

367
00:19:45,700 --> 00:19:49,300
could use certain things Within 
These parameters and we won't 

368
00:19:49,300 --> 00:19:52,200
ask anything. 
But if you have to go outside of

369
00:19:52,200 --> 00:19:55,800
this, then you have to come and 
justify why we are not saying 

370
00:19:55,800 --> 00:19:58,100
no, but at least come and 
justify why. 

371
00:19:58,500 --> 00:20:01,800
So at some places, we have come 
up with a flow chart for picking

372
00:20:01,800 --> 00:20:03,700
the right database for its 
right. 

373
00:20:03,700 --> 00:20:07,000
So you go through this tree of 
information, decision-making, 

374
00:20:07,000 --> 00:20:09,200
tree and then you arrive at 
something. 

375
00:20:09,500 --> 00:20:12,100
And if you want to use that 
file, You make me want ask 

376
00:20:12,100 --> 00:20:14,600
anything, you just start using 
it, but if you arrived at that 

377
00:20:14,600 --> 00:20:17,300
decision and you say, oh, that 
other thing over there is better

378
00:20:17,300 --> 00:20:20,700
than this, for my use case, then
you should have a conversation 

379
00:20:20,700 --> 00:20:24,200
someone before you pick that up.
So architecture, governance 

380
00:20:24,200 --> 00:20:28,000
matters a lot in this kind of 
scenarios because for solution 

381
00:20:28,000 --> 00:20:31,000
sake purposes, that may be 
great, but for million and sake,

382
00:20:31,000 --> 00:20:34,000
operational sick that other 
thing over there is a hindrance 

383
00:20:34,000 --> 00:20:36,400
from the operational side. 
So you have to have very good 

384
00:20:36,400 --> 00:20:40,000
reasons why that is this. 
So that's one the other it is 

385
00:20:40,200 --> 00:20:43,700
sometimes And to pick 
Technologies or Skies 

386
00:20:43,700 --> 00:20:47,800
architecture sites based on our 
own biases of understand. 

387
00:20:48,000 --> 00:20:52,200
I, if I am a data type of 
person, my bias is to make sure 

388
00:20:52,300 --> 00:20:55,100
all data is correct. 
I have taken care of very low 

389
00:20:55,100 --> 00:20:57,600
doses, right? 
Load versus really low and all 

390
00:20:57,600 --> 00:21:00,000
that kind of stuff. 
And then do the right kind of 

391
00:21:00,000 --> 00:21:01,800
design. 
But somebody else coming from 

392
00:21:01,800 --> 00:21:04,800
the other side may not be 
thinking about those things they

393
00:21:04,800 --> 00:21:07,600
may be thinking about what is a 
rarity, they may be thinking 

394
00:21:07,600 --> 00:21:10,500
about coupling versus 
orchestration versus 

395
00:21:10,600 --> 00:21:12,700
choreography. 
He and a bunch of others, all 

396
00:21:12,700 --> 00:21:15,400
valid concerns. 
But when you don't pair that 

397
00:21:15,400 --> 00:21:19,100
with the data side of the shop, 
then you end up like, hey, this 

398
00:21:19,100 --> 00:21:23,000
is all on software set is All By
Design but I am taking all of 

399
00:21:23,000 --> 00:21:25,900
that and storing it as blob, 
somewhere that nobody else can 

400
00:21:25,900 --> 00:21:29,100
read and then you have visited 
with Corpus of modularity 

401
00:21:29,100 --> 00:21:32,600
because now the data said you're
not model so stuff like that 

402
00:21:32,600 --> 00:21:34,900
matters. 
So that's why I say, like any 

403
00:21:34,900 --> 00:21:39,000
kind of new stuff comes up. 
They should one other place 

404
00:21:39,000 --> 00:21:41,900
where I think this painting 
really helps is And product 

405
00:21:41,900 --> 00:21:45,000
managers are business, people 
are coming up with new ideas, 

406
00:21:45,300 --> 00:21:47,900
and they are saying, let's at 
least for by out and see, okay? 

407
00:21:47,900 --> 00:21:51,100
How much this will cost is this 
your physical and stuff? 

408
00:21:51,500 --> 00:21:54,200
And they generally tend to talk 
to The Architects and say, oh, 

409
00:21:54,200 --> 00:21:57,400
is this a workable? 
Next with the data, it should 

410
00:21:57,400 --> 00:22:00,100
also be because they can tell 
you, where can I get the data 

411
00:22:00,100 --> 00:22:02,000
from? 
Where is the data available? 

412
00:22:02,000 --> 00:22:05,700
Do we have this kind of data 
available and stuff like that. 

413
00:22:05,700 --> 00:22:09,900
Then also give you a way to make
the feasibility question, answer

414
00:22:10,100 --> 00:22:13,600
in a complete sense. 
So the other place is also to 

415
00:22:13,600 --> 00:22:17,300
talk about especially on the 
analytic side like are reporting

416
00:22:17,300 --> 00:22:20,400
side of things like that. 
How is data being given to you? 

417
00:22:20,400 --> 00:22:22,200
What is the lineage of that 
data? 

418
00:22:22,400 --> 00:22:25,900
How what kind of Transformations
are like? 

419
00:22:25,900 --> 00:22:27,800
What are the standards being 
followed? 

420
00:22:27,800 --> 00:22:31,800
What kind of quality rules you 
are in application development? 

421
00:22:31,800 --> 00:22:35,200
I think that living standards 
quality standards bunch of those

422
00:22:35,200 --> 00:22:38,900
kinds of stuff is way of data 
people can really help because 

423
00:22:38,900 --> 00:22:41,900
if app is gone through 
development or Going to software

424
00:22:41,900 --> 00:22:44,000
has gone from development for 
ten iterations. 

425
00:22:44,500 --> 00:22:47,400
And then you tell, oh, this 
quality rule. 

426
00:22:47,400 --> 00:22:50,500
This standard has to be applied,
nobody's going to listen to you,

427
00:22:50,500 --> 00:22:54,200
because there's no time now 
because the D, or the product 

428
00:22:54,200 --> 00:22:57,100
manager of the product owner is 
going to say, I don't have time.

429
00:22:57,100 --> 00:22:59,700
I need to take this to Market, 
and now, you're carrying that 

430
00:22:59,700 --> 00:23:04,100
TechNet forever instead. 
If there was only your you have 

431
00:23:04,100 --> 00:23:07,000
talked to them, you would have 
gotten those unique standards, 

432
00:23:07,000 --> 00:23:09,100
you would have put all those 
things in place. 

433
00:23:09,500 --> 00:23:13,400
So you would not have that. 
So stuff like that, but 

434
00:23:13,500 --> 00:23:16,500
developer type level those 
things matter a lot over a 

435
00:23:16,500 --> 00:23:19,300
period of time. 
The other thing also is probably

436
00:23:19,300 --> 00:23:22,900
coaching and mentoring in there 
should be a constant flow of 

437
00:23:22,900 --> 00:23:26,200
ideas from software side to the 
hate, aside from the data side 

438
00:23:26,200 --> 00:23:29,900
to a software service, and those
could be like, what can I use 

439
00:23:29,900 --> 00:23:32,300
for certain things right? 
There may be some techniques, I 

440
00:23:32,308 --> 00:23:36,000
can use on the data side that 
can scale this much easier 

441
00:23:36,100 --> 00:23:39,500
versus use killing the app side 
like crazy, right? 

442
00:23:39,800 --> 00:23:43,200
They made some things, I In say 
he'll if a package this data up 

443
00:23:43,200 --> 00:23:46,200
and give it to you, then you can
distribute it much easier than 

444
00:23:46,200 --> 00:23:48,300
me, coming up on the data set 
its side. 

445
00:23:48,400 --> 00:23:51,500
So those give-and-take, I think 
as a team you can come up with a

446
00:23:51,508 --> 00:23:54,500
better solution. 
Thank you for sharing all these 

447
00:23:54,500 --> 00:23:57,200
areas of concerns. 
And the I have to say for me 

448
00:23:57,200 --> 00:23:59,700
personally as well dealing with 
data related Tech. 

449
00:23:59,700 --> 00:24:03,100
That is not fun first, it's like
a resume, it's risky. 

450
00:24:03,100 --> 00:24:06,700
Also and second thing is how we 
deal with the existing data, 

451
00:24:06,700 --> 00:24:08,500
right? 
Sometimes we have to patch them,

452
00:24:08,500 --> 00:24:11,600
migrate them and do all these 
stuffs in order to comply with 

453
00:24:11,600 --> 00:24:14,000
the new decisions, right? 
So I think it's always not fun 

454
00:24:14,400 --> 00:24:17,500
and I think that you said if you
can deal with it earlier that is

455
00:24:17,500 --> 00:24:20,800
always the best preferred 
options you mentioned earlier as

456
00:24:20,800 --> 00:24:23,500
well about picking the right. 
It database types, right. 

457
00:24:23,500 --> 00:24:26,300
And these days, I think I 
remember when I read your book, 

458
00:24:26,308 --> 00:24:29,700
nosql distilled long time ago, 
there was probably only four 

459
00:24:29,700 --> 00:24:33,100
types of databases like the 
document, the graph, the key 

460
00:24:33,100 --> 00:24:35,500
value store. 
But these days, there are so 

461
00:24:35,500 --> 00:24:37,700
many. 
In fact, there are plenty of new

462
00:24:37,700 --> 00:24:41,900
database companies being formed 
with their different type of 

463
00:24:41,900 --> 00:24:44,800
characteristics. 
So maybe if you can guide us 

464
00:24:44,800 --> 00:24:48,600
also for people here who are new
with many different types of 

465
00:24:48,600 --> 00:24:51,200
databases. 
Well what will be some of the 

466
00:24:51,200 --> 00:24:54,500
attributes or Three sticks that 
we should think about whenever 

467
00:24:54,500 --> 00:24:57,300
we want to pick the right 
database for our workload. 

468
00:24:57,300 --> 00:25:00,500
Of our use case, maybe some 
guidance here would be great. 

469
00:25:01,200 --> 00:25:03,400
Sure. 
I think there are three or four 

470
00:25:03,400 --> 00:25:06,200
things at a very high level that
you need to think about. 

471
00:25:06,500 --> 00:25:09,600
And then you can go down as you 
go down, you can have more 

472
00:25:09,600 --> 00:25:13,900
choices to worry about the what 
is productivity like right now, 

473
00:25:13,900 --> 00:25:16,100
human time costs, more than 
anything else. 

474
00:25:16,500 --> 00:25:20,300
So if you are working longer 
hours that cost is much more 

475
00:25:20,300 --> 00:25:22,200
than the cost of any other 
technology. 

476
00:25:22,300 --> 00:25:25,000
Ey. 
So, if something makes you more 

477
00:25:25,000 --> 00:25:28,400
productive like, for example, if
you're writing JavaScript and 

478
00:25:28,400 --> 00:25:32,400
node.js and stuff, I have Json, 
I just need to store the Json 

479
00:25:32,400 --> 00:25:35,000
and retrieve the Json. 
Go document. 

480
00:25:35,000 --> 00:25:39,200
I spy database has been a simple
choice, so I think productivity 

481
00:25:39,200 --> 00:25:41,600
is one thing that drives a lot 
of these decisions. 

482
00:25:41,600 --> 00:25:43,300
Like, oh, this thing makes me 
productive. 

483
00:25:43,400 --> 00:25:45,800
I don't need to worry about 
other stuff and then the other 

484
00:25:45,800 --> 00:25:48,400
decisions, they'll optimize 
later, but that's the primary 

485
00:25:48,400 --> 00:25:52,800
decision. 
The second is sometimes use 

486
00:25:52,800 --> 00:25:57,300
cases which need not of thought 
to be picking the right 

487
00:25:57,300 --> 00:26:00,400
database. 
What I mean by that is let's say

488
00:26:00,400 --> 00:26:03,800
there is some use case where you
have like oh I need to store 

489
00:26:03,800 --> 00:26:08,200
like trillions of rows and that 
won't fit in a single machine. 

490
00:26:08,400 --> 00:26:11,700
So I need to find something that
can distribute itself, easily, 

491
00:26:11,700 --> 00:26:15,400
shower date, or whatever. 
So let me find the right type of

492
00:26:16,500 --> 00:26:19,600
or they may be some instances 
where you say, oh I have this 

493
00:26:19,600 --> 00:26:22,500
external. 
The fire that I always have and 

494
00:26:22,500 --> 00:26:24,800
I can get data based on that, 
always, alright? 

495
00:26:24,800 --> 00:26:29,400
Lee and based on that then you 
pick the style for that type of 

496
00:26:29,400 --> 00:26:31,100
thing. 
So like what are my read 

497
00:26:31,100 --> 00:26:33,000
patterns and what are my weight 
times? 

498
00:26:33,600 --> 00:26:36,800
You need to analyze that a 
little bit and figure out what 

499
00:26:36,800 --> 00:26:39,300
is the style of database that 
works for that? 

500
00:26:39,500 --> 00:26:43,300
And the reason I'm saying is 
twenty years ago, we used to 

501
00:26:43,300 --> 00:26:46,000
think a lot about this space. 
How much disk space we have 

502
00:26:46,000 --> 00:26:49,900
using, and the cost of the disk 
space and all that stuff. 

503
00:26:50,700 --> 00:26:54,000
Today, the amount of time you 
spend in thinking about that 

504
00:26:54,200 --> 00:26:58,100
will pay for this, right? 
So, the cost of the disk space 

505
00:26:58,100 --> 00:27:01,500
is no longer a question. 
So it's more about how much can 

506
00:27:01,500 --> 00:27:04,000
I write on my skin? 
I read, how fast can I read how 

507
00:27:04,000 --> 00:27:05,900
fast you are? 
Need to read and a bunch of 

508
00:27:05,900 --> 00:27:09,100
that, kind of questions come 
into play and then you pick the 

509
00:27:09,100 --> 00:27:12,200
right kind of database for that.
Like, some databases you write 

510
00:27:12,200 --> 00:27:14,200
only once but we'd be in 
sometimes. 

511
00:27:14,200 --> 00:27:17,500
So then maybe you need something
that is read performant and I 

512
00:27:17,500 --> 00:27:20,300
may want to write the same data 
34 times in. 

513
00:27:20,500 --> 00:27:24,000
Different styles like different.
Aggregations Sky, that's fine 

514
00:27:24,000 --> 00:27:26,900
because I'm reading so many 
times and I want to make Vida 

515
00:27:26,900 --> 00:27:28,800
fishing. 
It's our other places. 

516
00:27:29,100 --> 00:27:32,400
The right efficiency in a matter
of a lot, because data is coming

517
00:27:32,400 --> 00:27:35,500
so fast at you and you want to 
make sure you can write to write

518
00:27:35,500 --> 00:27:38,700
efficiency. 
So then you pick something that 

519
00:27:39,000 --> 00:27:42,700
caters to, right? 
And the third style is, what is 

520
00:27:42,700 --> 00:27:44,900
it that you want to get out of 
that database, right? 

521
00:27:44,900 --> 00:27:48,600
Like for analytical proposals 
are you doing lots of rows of 

522
00:27:48,600 --> 00:27:51,800
executions that kind of stuff. 
So let me pick something that 

523
00:27:51,800 --> 00:27:54,200
helps that. 
Or are you doing like graph 

524
00:27:54,200 --> 00:27:58,900
traversal or graph analytics or 
relational analytics or that 

525
00:27:58,900 --> 00:28:01,000
kind of stuff, right? 
So let me pick something that 

526
00:28:01,600 --> 00:28:04,500
works for that. 
And nowadays, there are many 

527
00:28:04,500 --> 00:28:07,900
databases that coming up, but if
you really look deeper 

528
00:28:08,300 --> 00:28:10,100
classically, there are like five
types. 

529
00:28:10,300 --> 00:28:14,600
It's at a very broad level like 
relational databases key value 

530
00:28:14,600 --> 00:28:19,700
stores documents and databases 
white column stores and crafts 

531
00:28:19,700 --> 00:28:21,800
stores. 
So most of them kind of fit in 

532
00:28:21,800 --> 00:28:24,400
this style. 
Like even a block storage is 

533
00:28:24,400 --> 00:28:26,300
nothing but a key value writing 
a Blog. 

534
00:28:26,400 --> 00:28:29,000
The file in is a key. 
Everything inside is a whale, 

535
00:28:29,000 --> 00:28:30,800
right? 
If you think about it, that way,

536
00:28:31,400 --> 00:28:34,100
then there are five big pipes 
and then you can decide which 

537
00:28:34,100 --> 00:28:37,500
type of database that you want 
to look at and then you can 

538
00:28:37,900 --> 00:28:40,200
within that type. 
Then there may be multiple 

539
00:28:40,300 --> 00:28:44,200
Choices available and then you 
pick based on that, right? 

540
00:28:44,200 --> 00:28:47,600
So if you take an example of how
I need a graph database because 

541
00:28:47,600 --> 00:28:51,700
I'm doing graph traversal fine. 
Now you have options of year for

542
00:28:51,700 --> 00:28:55,900
Jay, Neptune, DeGraff tiger 
grass and a bunch of other 

543
00:28:55,900 --> 00:28:58,600
choices. 
Now, how do you pick that? 

544
00:28:58,600 --> 00:29:01,500
Choice is a question that always
comes out, right? 

545
00:29:01,900 --> 00:29:05,000
And then do that. 
Generally what I tend to do is 

546
00:29:05,000 --> 00:29:09,200
set up our scoring Matrix of 
what is it that I would pay 

547
00:29:09,200 --> 00:29:11,600
right in this graph? 
The sense, I can pick new Forge 

548
00:29:11,600 --> 00:29:15,500
a paragraph B graph and Neptune 
put them on like a header type 

549
00:29:15,500 --> 00:29:18,100
of stuff. 
And I have metrics on which I 

550
00:29:18,100 --> 00:29:20,900
want to measure because every 
company can have different 

551
00:29:20,900 --> 00:29:23,600
measurements, right? 
Some people may say familiar, it

552
00:29:23,600 --> 00:29:26,900
is very important, and I have 
people who know neo4j, so no 

553
00:29:26,900 --> 00:29:31,000
discussion for me. 
I just some people will say, oh,

554
00:29:31,000 --> 00:29:36,100
I don't want to leave the ews 
landscape that we are in, so 

555
00:29:36,100 --> 00:29:37,700
I'll just pick Neptune in. 
You're done. 

556
00:29:38,000 --> 00:29:41,500
Some people may say open source 
matters, Me and distributed 

557
00:29:41,500 --> 00:29:45,100
databases matter to me and that 
kind of stuff by nodes are gonna

558
00:29:45,100 --> 00:29:47,800
be really large. 
So I need distributed graph 

559
00:29:47,800 --> 00:29:50,200
database. 
So people will say, okay will be

560
00:29:50,200 --> 00:29:54,700
graph so that I think is what 
you need to set up for your own 

561
00:29:54,700 --> 00:29:57,700
company or your own situation, 
and come up with. 

562
00:29:57,700 --> 00:30:00,800
What are you going to measure 
the products on, right? 

563
00:30:00,800 --> 00:30:04,600
So set up a rubric for yourself 
and that score, these products, 

564
00:30:04,800 --> 00:30:06,400
very easy. 
In fact, most of them you can 

565
00:30:06,400 --> 00:30:09,800
try, you can run up, you'll see,
you can do some research. 

566
00:30:10,200 --> 00:30:13,000
And then set up that rubric and 
score yourself. 

567
00:30:13,300 --> 00:30:16,600
And the answer will just hopping
speech and then you click one 

568
00:30:16,700 --> 00:30:19,200
based on. 
Thank you for the guideline. 

569
00:30:19,200 --> 00:30:22,300
I think is really interesting 
the way you first mention about 

570
00:30:22,300 --> 00:30:25,300
the ease of use or the 
productivity, right? 

571
00:30:25,300 --> 00:30:27,900
So based on the developers or 
the language stack, that you are

572
00:30:27,900 --> 00:30:31,700
using one question related to 
that, in my experience working 

573
00:30:31,700 --> 00:30:34,800
in multiple projects and 
different types of products. 

574
00:30:35,100 --> 00:30:38,300
One thing that always happens is
that I've heard multiple times, 

575
00:30:38,600 --> 00:30:41,000
they develop choose a certain 
Database. 

576
00:30:41,200 --> 00:30:44,300
It works well in the beginning 
but after a while, it didn't 

577
00:30:44,400 --> 00:30:47,900
perform or it doesn't skill and 
a lot of learnings as well. 

578
00:30:47,900 --> 00:30:51,600
Also point out that eventually 
actually many people referred 

579
00:30:51,600 --> 00:30:54,900
back to rdbms, you know, things 
starting to become like a big 

580
00:30:54,900 --> 00:30:58,400
quickest again, right? 
With rdbms may be either MySQL 

581
00:30:58,400 --> 00:31:00,700
and postgres or even Cloud 
databases. 

582
00:31:00,700 --> 00:31:04,200
These days also have rdbms 
compliant interfaces, although 

583
00:31:04,200 --> 00:31:06,900
maybe the way they store or 
query is different. 

584
00:31:07,200 --> 00:31:10,000
So I'm interested to hear your 
thoughts about this coming. 

585
00:31:10,200 --> 00:31:12,500
Back to sequel. 
Coming back to rdbms. 

586
00:31:12,800 --> 00:31:15,100
Is it still the preferred 
default choice? 

587
00:31:15,100 --> 00:31:18,200
That people should choose. 
And when you talk about 

588
00:31:18,200 --> 00:31:21,100
readwrite patterns as well, 
maybe if you can give rough 

589
00:31:21,100 --> 00:31:24,800
ideas when there's rdbms 
actually does not scale that 

590
00:31:24,800 --> 00:31:27,600
people need to start thinking 
about other types of database. 

591
00:31:28,500 --> 00:31:32,200
So many a times when people pick
up new types of databases for 

592
00:31:32,200 --> 00:31:35,200
themselves, they have picked a 
new database but they're 

593
00:31:35,200 --> 00:31:38,100
designed thinking still is in 
the relational world. 

594
00:31:38,300 --> 00:31:41,600
So I have seen a lot of document
database, This is where the 

595
00:31:41,600 --> 00:31:45,100
collections have been designed 
as if they have tables and then 

596
00:31:45,300 --> 00:31:48,300
the complaint comes in, like, I 
can join this Corrections. 

597
00:31:48,700 --> 00:31:51,300
A document database is not 
supposed to join collections. 

598
00:31:51,300 --> 00:31:54,100
You have to have like a 
aggregate version of the 

599
00:31:54,108 --> 00:31:56,900
collections, right? 
That's where this domain driven 

600
00:31:56,900 --> 00:31:59,000
design, way of thinking really 
helps. 

601
00:31:59,000 --> 00:32:01,800
So, in the nosql distill book, 
we talk about what is the 

602
00:32:01,800 --> 00:32:05,200
boundary of you're a greedy. 
So good example of this would be

603
00:32:05,400 --> 00:32:08,400
lets say e-commerce system. 
You have a customer that has 

604
00:32:08,400 --> 00:32:13,300
multiple orders and each order 
as ordered by items as payment 

605
00:32:13,300 --> 00:32:16,500
information shipping 
information, probably packaging 

606
00:32:16,500 --> 00:32:18,300
information on it. 
Like is it a gift? 

607
00:32:18,300 --> 00:32:22,400
Not a gift that can stop right 
in a relational way of thinking.

608
00:32:22,600 --> 00:32:25,800
You have a customer table, we 
have addressed legally, have 

609
00:32:25,800 --> 00:32:29,100
ordered it when you have order 
item table, probably have a 

610
00:32:29,100 --> 00:32:31,800
payment information and bunch of
these states. 

611
00:32:31,800 --> 00:32:34,000
Right? 
And when you go to document 

612
00:32:34,000 --> 00:32:37,700
databases, you can say oh I'll 
take that idea and just have 

613
00:32:37,700 --> 00:32:40,100
multiple elections of these 
things. 

614
00:32:40,200 --> 00:32:43,200
I have a customer collection, I 
have a dress collection and that

615
00:32:43,200 --> 00:32:47,100
NASA, because when you put this 
back together, you have split 

616
00:32:47,100 --> 00:32:49,400
the aggregate into a really 
small parts. 

617
00:32:49,700 --> 00:32:52,800
And now we have to put it all 
back together and the database 

618
00:32:52,800 --> 00:32:54,800
was not break for putting all 
those things. 

619
00:32:54,800 --> 00:32:58,400
Like, so where do you pick your 
aggregate boundary? 

620
00:32:58,700 --> 00:33:01,700
One example would be. 
I have a customer agree, gay 

621
00:33:02,100 --> 00:33:04,500
inside the customer we get. 
I have all the customer 

622
00:33:04,500 --> 00:33:08,500
information and I have a 
collection or a list of orders 

623
00:33:08,500 --> 00:33:12,200
inside it, and then eat, Order 
in turn the Json object. 

624
00:33:12,200 --> 00:33:15,900
If we think about it will have 
the order Handler will have the 

625
00:33:15,900 --> 00:33:18,200
order items. 
We have to paint everything all 

626
00:33:18,200 --> 00:33:20,500
inside. 
So when you go to the database 

627
00:33:20,500 --> 00:33:24,000
and you pull the customer out, 
everything comes with it, so 

628
00:33:24,000 --> 00:33:27,400
that's one and somebody may say,
oh what is a customer has 

629
00:33:27,400 --> 00:33:29,900
thousands of orders. 
Then my objects will become too 

630
00:33:29,900 --> 00:33:32,700
big, like, you're transporting 
all of that over the wire, 

631
00:33:32,700 --> 00:33:35,600
sending it all back. 
Okay, now it's time to think 

632
00:33:35,600 --> 00:33:38,500
about how the split disagree 
it's to be. 

633
00:33:39,000 --> 00:33:42,500
So then you can say, oh, Want to
have a customer Aggregate and I 

634
00:33:42,500 --> 00:33:44,400
have what I have orders. 
Agree. 

635
00:33:44,600 --> 00:33:48,000
So you have one object for 
customers that has all the 

636
00:33:48,000 --> 00:33:51,700
customer information, probably 
their preferred shipping address

637
00:33:51,700 --> 00:33:55,000
before, packaging whatever and 
then you have one object for 

638
00:33:55,000 --> 00:33:57,900
each order and the order has a 
reference back to the custom. 

639
00:33:58,600 --> 00:34:01,400
So when you go back to when you 
want to show, all the orders 

640
00:34:01,400 --> 00:34:03,900
about the customer, you go to 
the customer, pick up the 

641
00:34:03,900 --> 00:34:07,000
customer and then go to the 
orders list and say, give me all

642
00:34:07,000 --> 00:34:08,600
the orders that have this 
customer. 

643
00:34:09,100 --> 00:34:12,100
So now you have split the eye. 
Aggregate but not too much just 

644
00:34:12,100 --> 00:34:14,500
a little bit so that it can 
manage this one. 

645
00:34:14,900 --> 00:34:17,400
So you have to think about these
kinds of stuff because when you 

646
00:34:17,400 --> 00:34:19,699
go back to the standard 
relational way of thinking and 

647
00:34:19,699 --> 00:34:24,000
you speak too much, of course 
databases, So, I think the first

648
00:34:24,000 --> 00:34:26,600
thing generally, I recommend 
when people pick a new database 

649
00:34:26,600 --> 00:34:30,500
style, is do pet project. 
Like, don't do your actual 

650
00:34:30,500 --> 00:34:33,600
project look at project play 
with it, try to understand, 

651
00:34:33,600 --> 00:34:35,300
okay, how do I need to think 
about it? 

652
00:34:35,500 --> 00:34:38,199
How do I need to worry about it 
is need to get training, get 

653
00:34:38,199 --> 00:34:40,300
training. 
If you need to like talk to 

654
00:34:40,300 --> 00:34:43,600
someone who's experienced in 
that database, talk to them, 

655
00:34:44,199 --> 00:34:47,100
understand this design patterns 
that are different. 

656
00:34:48,199 --> 00:34:51,300
So again the classic example 
would be like graph traversal, 

657
00:34:51,300 --> 00:34:54,600
for example, some Probably say, 
oh, graph traversal. 

658
00:34:54,600 --> 00:34:57,400
I can do this in databases, 
like, relational databases. 

659
00:34:57,600 --> 00:35:01,700
I just put pointers and stuff 
and after two or three levels of

660
00:35:01,700 --> 00:35:06,800
whiter, you'll figure out 
relational databases to work and

661
00:35:06,800 --> 00:35:10,300
then they go to graph databases.
And then in graph databases, 

662
00:35:10,400 --> 00:35:14,300
they start treating each node as
if it is a table, it is not. 

663
00:35:14,300 --> 00:35:18,000
It is a single instance of row 
that is connected to something 

664
00:35:18,000 --> 00:35:18,900
else. 
Alright? 

665
00:35:19,000 --> 00:35:21,900
So we have to think about these 
things a little bit differently 

666
00:35:22,500 --> 00:35:26,000
and Then you realize that the 
gains of using that technology. 

667
00:35:26,300 --> 00:35:28,600
So I think that is what I would 
recommend people. 

668
00:35:28,600 --> 00:35:30,500
Like figure out how this tool 
Works. 

669
00:35:30,800 --> 00:35:34,200
Get some training topic, someone
who's experienced play with it a

670
00:35:34,207 --> 00:35:37,300
little bit, solve a simple 
problem or something and 

671
00:35:37,300 --> 00:35:41,500
understand how this thing works.
One other thing I have also done

672
00:35:41,500 --> 00:35:45,800
is if you know that in this 
space of this database type, I 

673
00:35:45,800 --> 00:35:48,800
need to pick one technology that
was talking about the rubric 

674
00:35:48,800 --> 00:35:51,100
before, right? 
So performance can also be a 

675
00:35:51,107 --> 00:35:54,800
rubric on that like, does it 
Handle of billion notes, for 

676
00:35:54,800 --> 00:35:58,300
example, or does it handle a 
billion documents? 

677
00:35:58,500 --> 00:36:01,000
So put a billion documents 
nowadays, you can create fake 

678
00:36:01,000 --> 00:36:04,000
data, put it in the database and
see how it works. 

679
00:36:04,100 --> 00:36:07,100
Setting up that experiment, we 
take a little bit of time but it

680
00:36:07,100 --> 00:36:09,000
will save you time in the 
future. 

681
00:36:09,300 --> 00:36:13,200
So create a framework or create 
like a harness, which puts in 

682
00:36:13,200 --> 00:36:16,600
all this data in there and then 
you run your query load. 

683
00:36:16,600 --> 00:36:18,300
And this is where knowing you're
pretty pattern. 

684
00:36:18,300 --> 00:36:20,800
Makes a lot of sense. 
Like if you don't know how many 

685
00:36:20,800 --> 00:36:23,500
rights and how many reads you 
have it, Cannot set up a 

686
00:36:23,500 --> 00:36:27,900
performance harness. 
So you basically once you've set

687
00:36:27,900 --> 00:36:31,500
up like a billion documents for 
example, and then you know, can 

688
00:36:31,500 --> 00:36:35,900
going to do like 60% of my load 
is read forty percent is right. 

689
00:36:36,100 --> 00:36:39,800
Okay, so what does that mean in 
one hours of production time, 

690
00:36:40,200 --> 00:36:41,500
I'm going to do this many 
nights. 

691
00:36:41,500 --> 00:36:43,600
I'm going to do this video 
reads, right? 

692
00:36:43,600 --> 00:36:45,500
Okay. 
Set that up and run it and see 

693
00:36:45,500 --> 00:36:48,000
what it does and then you will 
figure out. 

694
00:36:48,000 --> 00:36:50,200
Okay, should I change my design 
pattern? 

695
00:36:50,200 --> 00:36:53,300
Should I change my product, 
should I change my Bye. 

696
00:36:53,300 --> 00:36:55,800
Should I change my technology? 
Whatever it is. 

697
00:36:55,800 --> 00:36:59,500
It tells you where you need to 
focus, I think you're sharing 

698
00:36:59,500 --> 00:37:01,500
about. 
The aggregate boundary is gold. 

699
00:37:01,500 --> 00:37:05,000
I feel this will save a lot of 
developers time and effort as 

700
00:37:05,000 --> 00:37:07,200
well. 
I think it's a very good advice 

701
00:37:07,200 --> 00:37:09,900
that we have to look maybe from 
the use case the business use 

702
00:37:09,900 --> 00:37:13,100
case product requirements. 
What kind of aggregate boundary 

703
00:37:13,100 --> 00:37:17,000
that we are dealing with right 
and then not to use the old 

704
00:37:17,000 --> 00:37:21,300
paradigms, the rdbms, these data
modeling, apply to different 

705
00:37:21,300 --> 00:37:24,400
types of databases which is Is 
probably a majority of 

706
00:37:24,408 --> 00:37:26,300
performance issues come from 
there, right? 

707
00:37:26,300 --> 00:37:29,200
So the impedance mismatch 
between the data model and how 

708
00:37:29,200 --> 00:37:31,900
you query them. 
So, thanks for sharing that. 

709
00:37:32,000 --> 00:37:35,200
The other thing that I want to 
ask is about whenever we have 

710
00:37:35,200 --> 00:37:38,200
all these data types. 
Now, people tend to think about 

711
00:37:38,200 --> 00:37:41,800
touring special type of data 
into different databases or what

712
00:37:41,800 --> 00:37:44,100
we call also polyglot 
persistence, right? 

713
00:37:44,200 --> 00:37:46,600
Especially now with the 
microservices, maybe one service

714
00:37:46,600 --> 00:37:49,800
could have multiple databases 
but it also comes with a hard 

715
00:37:49,800 --> 00:37:52,100
challenge, right? 
It's about the transaction. 

716
00:37:52,500 --> 00:37:55,500
I It's always very important to 
think about transaction, and 

717
00:37:55,500 --> 00:37:58,900
especially with polyglot, 
persistence multiple data types,

718
00:37:58,900 --> 00:38:00,800
right? 
How do you have this in a 

719
00:38:00,800 --> 00:38:03,900
distributed manner? 
So maybe from your view, how 

720
00:38:03,900 --> 00:38:07,500
should we think about managing 
all these transactions may be 

721
00:38:07,700 --> 00:38:10,100
multiple databases if they are 
involved, right? 

722
00:38:10,200 --> 00:38:12,800
Is there any special thing that 
we have to think about? 

723
00:38:13,200 --> 00:38:15,600
Yeah. 
So I think that is always such a

724
00:38:15,600 --> 00:38:18,700
use case, specific discussion 
that needs to be had with the 

725
00:38:18,700 --> 00:38:22,300
business like one thing I've 
realized in the past probably 15

726
00:38:22,300 --> 00:38:24,300
years. 
Is this whole notion of 

727
00:38:24,300 --> 00:38:28,300
transaction and consistency and 
acid compliance and all that 

728
00:38:28,300 --> 00:38:33,900
stuff is many a times, a 
composed, as in all the business

729
00:38:33,900 --> 00:38:35,800
wants is don't lose my 
transaction. 

730
00:38:35,800 --> 00:38:39,000
They don't really care if it's 
like acid compliant or this or 

731
00:38:39,000 --> 00:38:42,100
that, right? 
So many times I always tend to 

732
00:38:42,100 --> 00:38:45,400
go back to this discussion of 
how much money do you want to 

733
00:38:45,400 --> 00:38:48,100
put? 
Like, money is a proxy for time 

734
00:38:48,100 --> 00:38:50,000
here. 
Basically, how much money do you

735
00:38:50,008 --> 00:38:54,100
want to invest to make this as a
top client or This 100% 

736
00:38:54,100 --> 00:38:57,700
consistent or whatever, and the 
business should be driving that,

737
00:38:57,800 --> 00:38:59,800
right? 
They should be saying it's okay 

738
00:38:59,800 --> 00:39:01,700
if it's famously. 
Okay, then I have a different 

739
00:39:01,700 --> 00:39:05,500
solution for that worship. 
Someone say, oh, I need to make 

740
00:39:05,500 --> 00:39:09,500
sure all stores are consistent 
all the time and that cost a 

741
00:39:09,508 --> 00:39:11,200
lot. 
And is a totally different 

742
00:39:11,200 --> 00:39:14,300
solution. 
And we as technologists, cannot 

743
00:39:14,300 --> 00:39:16,500
make that decision or should not
make that decision. 

744
00:39:16,700 --> 00:39:19,500
It's the business that should 
make that decision because they 

745
00:39:19,500 --> 00:39:22,000
are the one who are deciding, 
how is it that they want their 

746
00:39:22,000 --> 00:39:24,000
data. 
How is it that they want their 

747
00:39:24,000 --> 00:39:27,700
systems and how much do they 
want to invest in that desire 

748
00:39:27,700 --> 00:39:30,500
that they have? 
So we should expose this to 

749
00:39:30,500 --> 00:39:32,200
their business. 
That's the first thing I want to

750
00:39:32,200 --> 00:39:34,900
say. 
The second thing is let's say 

751
00:39:34,900 --> 00:39:38,900
someone says, I need a highly 
consistent database or highly 

752
00:39:38,900 --> 00:39:41,700
consistent data then, okay. 
What are the patterns in which 

753
00:39:41,700 --> 00:39:44,800
we can implement the consistence
that comes into play? 

754
00:39:45,000 --> 00:39:48,500
And then within a micro service,
if you have, let's see more than

755
00:39:48,500 --> 00:39:51,800
one database. 
Then how do I make sure they 

756
00:39:51,800 --> 00:39:54,500
consistency? 
Of the rights that are going on.

757
00:39:55,200 --> 00:39:58,100
And in most statistical, test 
systems, even if you're writing 

758
00:39:58,100 --> 00:40:01,700
to the same database, you will 
have consistency issues because 

759
00:40:01,700 --> 00:40:04,500
let's say you are writing to 
Cassandra which is a distributed

760
00:40:04,500 --> 00:40:07,100
database and the data mean reach
one node. 

761
00:40:07,200 --> 00:40:11,400
And you may say oh it's done but
that nor sales that we have lost

762
00:40:11,400 --> 00:40:13,400
in it. 
So you still have to think about

763
00:40:13,400 --> 00:40:15,700
you and it's the same database 
you have to think about what are

764
00:40:15,700 --> 00:40:18,800
the consistency requirements 
that I consider. 

765
00:40:19,100 --> 00:40:21,800
So every right could have 
different consistency 

766
00:40:21,800 --> 00:40:24,600
requirements. 
Well, I'm writing just some kind

767
00:40:24,600 --> 00:40:28,000
of audit log that will be a 
little bit different consistency

768
00:40:28,000 --> 00:40:30,800
requirements versus I'm writing 
an order. 

769
00:40:31,300 --> 00:40:34,800
So every ripe you can decide 
what is your consistency level 

770
00:40:35,300 --> 00:40:38,100
and many of these databases 
especially if you're writing to 

771
00:40:38,100 --> 00:40:41,800
single database, provide you 
different types of consistency 

772
00:40:41,800 --> 00:40:44,800
guarantees, right? 
So I think they are called like 

773
00:40:45,100 --> 00:40:48,700
forum is one when it says 
majority of the nodes got it. 

774
00:40:48,900 --> 00:40:52,300
And then you can say, oh, just 
neck as long as one node, got 

775
00:40:52,300 --> 00:40:54,300
it. 
Find out as I go, there's more 

776
00:40:54,300 --> 00:40:57,700
than two notes have it? 
I'm fine Arabic in mongodb. 

777
00:40:57,700 --> 00:41:00,400
I think for example you can just
say, oh as long as the not 

778
00:41:00,400 --> 00:41:02,900
receive they can find. 
I don't even care if it does it 

779
00:41:02,900 --> 00:41:06,300
come to the desktop. 
So a bunch of these options are 

780
00:41:06,300 --> 00:41:10,000
available and it'll pick which 
option you want based on each 

781
00:41:10,000 --> 00:41:12,700
different type of right even 
within the same application. 

782
00:41:13,100 --> 00:41:17,100
So I think making these kinds of
decisions inside act like 

783
00:41:17,100 --> 00:41:20,200
probably a tech lead level or at
architecture level. 

784
00:41:20,500 --> 00:41:23,100
You can say oh this type of 
Rights will always Go with this 

785
00:41:23,100 --> 00:41:26,100
type of consistency, this type 
of Rights will go with this type

786
00:41:26,100 --> 00:41:28,700
of consistency and probably 
encoded and don't make the 

787
00:41:28,700 --> 00:41:31,700
developer think for every right.
Just have some kind of a 

788
00:41:31,700 --> 00:41:35,200
convention about it and you go. 
The other part is when you're 

789
00:41:35,200 --> 00:41:37,800
writing to two different 
databases, like one probably is 

790
00:41:37,800 --> 00:41:39,800
like, let's say you write a 
relational database and the 

791
00:41:39,800 --> 00:41:41,900
other is going to a graph 
database or something. 

792
00:41:42,300 --> 00:41:45,000
Then now, you are in this. 
Like, if I want to maintain 

793
00:41:45,000 --> 00:41:48,400
consistency like, a hundred 
percent consistency, what are 

794
00:41:48,400 --> 00:41:52,000
the patterns that are available 
and implementing those patterns 

795
00:41:52,000 --> 00:41:54,800
that you can use? 
Keep our transaction coordinator

796
00:41:54,800 --> 00:41:58,300
or something like a two-phase. 
Commit is a really hard problem 

797
00:41:58,400 --> 00:42:01,400
and you really need to think if 
I want it. 

798
00:42:01,700 --> 00:42:04,400
And what is the types of 
challenges are willing to take, 

799
00:42:04,400 --> 00:42:07,800
on Nick? 
So, Many Items, what happens in 

800
00:42:07,800 --> 00:42:10,400
a polyglot, like the relational 
and cross. 

801
00:42:10,600 --> 00:42:15,100
As an example, you are writing 
to relation now for operational 

802
00:42:15,100 --> 00:42:18,500
purposes and you're writing to 
graph or graph traversal 

803
00:42:18,500 --> 00:42:21,200
analytical, probably 
recommendation engine, that kind

804
00:42:21,200 --> 00:42:23,900
of purpose. 
And Those things can be 

805
00:42:23,900 --> 00:42:27,900
eventually consistent and 
relates now can be like 100% 

806
00:42:27,900 --> 00:42:29,800
classes. 
So you can even make a decision 

807
00:42:29,800 --> 00:42:32,700
between that like, what is use 
case in which I am writing to 

808
00:42:32,700 --> 00:42:36,100
multiple layers, right? 
So someone writes takes an 

809
00:42:36,100 --> 00:42:38,600
order, your forces, the order 
and the data. 

810
00:42:38,600 --> 00:42:41,700
Eventually within the next five,
ten seconds goes to the graph 

811
00:42:41,700 --> 00:42:44,600
database and some other person 
is going on web page. 

812
00:42:44,600 --> 00:42:46,800
And you want to show them a 
recommendation based on the 

813
00:42:46,808 --> 00:42:51,100
grass, how much wrong is it for 
the recommendation to not based 

814
00:42:51,100 --> 00:42:54,200
on this last outer material? 
That's a trade-off, right? 

815
00:42:54,500 --> 00:42:57,300
And you say no no it has to be 
in a hundred percent, all the 

816
00:42:57,300 --> 00:43:00,100
orders that are committed here. 
Recommendation, has to be based 

817
00:43:00,100 --> 00:43:04,000
on that, then you click pick a 
transaction coordinator, you put

818
00:43:04,000 --> 00:43:07,600
all this, the architecture 
complexity increases because of 

819
00:43:07,900 --> 00:43:10,900
right and that's a trade-off. 
You have to take on like oh I 

820
00:43:10,908 --> 00:43:13,100
cannot even be five seconds 
behind. 

821
00:43:13,300 --> 00:43:15,900
So I'm increasing my 
architecture complexity. 

822
00:43:16,300 --> 00:43:19,400
That's a bit of you mean and is 
it okay you should ask the 

823
00:43:19,400 --> 00:43:21,700
business, is it okay? 
And then if they say yes, that's

824
00:43:21,700 --> 00:43:24,200
how I want it. 
Then yes, then you increase the 

825
00:43:24,200 --> 00:43:27,200
architecture of complexity to 
meet that business, need the 

826
00:43:27,200 --> 00:43:29,100
introduced a transaction 
coordinator with the night 

827
00:43:29,100 --> 00:43:30,500
happens. 
Here you go there, right? 

828
00:43:30,500 --> 00:43:32,600
That side. 
And then of course, those come 

829
00:43:32,600 --> 00:43:35,300
with its own trade offs, 
introducing transaction 

830
00:43:35,300 --> 00:43:40,700
coordinator zookeeper, but then 
you made a informed choice about

831
00:43:40,700 --> 00:43:43,300
using. 
Thank you for sharing this 

832
00:43:43,300 --> 00:43:45,400
guidelines, right? 
I think it's really key for 

833
00:43:45,400 --> 00:43:48,100
people to hear, right? 
So always involve business, 

834
00:43:48,300 --> 00:43:51,100
whenever you make this type of 
decision, maybe sometimes 

835
00:43:51,100 --> 00:43:55,500
business actually don't require.
Real-time 100% consistent within

836
00:43:55,500 --> 00:43:58,100
milliseconds, right? 
Sometimes it could be delayed, 

837
00:43:58,100 --> 00:44:00,900
they accept delay. 
And knowing this is actually key

838
00:44:00,900 --> 00:44:03,000
whenever you create your 
solution, right? 

839
00:44:03,000 --> 00:44:05,800
Because then you can have 
different types of options. 

840
00:44:06,300 --> 00:44:08,400
So I have one interesting 
thought, right? 

841
00:44:08,400 --> 00:44:11,500
Whenever you said in the 
beginning, that it stuck in post

842
00:44:11,600 --> 00:44:15,100
and how much money or effort you
associate with choosing this, 

843
00:44:15,100 --> 00:44:17,000
right? 
But actually many types of this 

844
00:44:17,000 --> 00:44:19,800
decision, like you said, be 
stackin post is developers who 

845
00:44:19,800 --> 00:44:22,600
make the decision and actually 
from their arguments. 

846
00:44:22,700 --> 00:44:26,000
Choosing like an acid compliant 
database is actually much much 

847
00:44:26,000 --> 00:44:29,500
faster and saves a lot of effort
because you are when you deal 

848
00:44:29,500 --> 00:44:32,300
with eventual consistency, that 
means you need to write a lot 

849
00:44:32,300 --> 00:44:33,600
more code. 
You need to do a lot more 

850
00:44:33,600 --> 00:44:37,200
testing so maybe a little bit of
advice for developers here, 

851
00:44:37,200 --> 00:44:39,800
which I'm sure that we have 
plenty of a developer listeners,

852
00:44:40,300 --> 00:44:43,400
how we should think about the 
effort here because storing into

853
00:44:43,400 --> 00:44:45,500
an acid compliant is pretty well
known. 

854
00:44:45,500 --> 00:44:47,800
These days, there are Frameworks
very easy to do. 

855
00:44:48,000 --> 00:44:51,500
First was having to do it in an 
eventual, consistency Manner and

856
00:44:51,500 --> 00:44:53,600
the effort that requires Them to
do that. 

857
00:44:53,600 --> 00:44:55,800
So maybe an advice here for 
developers as well. 

858
00:44:56,500 --> 00:44:59,800
Yeah, certainly I made again, I 
like to think about everything 

859
00:44:59,800 --> 00:45:02,200
as a trade-off, right? 
So you when you say as it 

860
00:45:02,200 --> 00:45:06,300
complied it makes my life easy 
great, you traded off, Skilling 

861
00:45:06,300 --> 00:45:09,700
for that, right? 
So when skill comes in, then you

862
00:45:09,700 --> 00:45:12,700
start having this replicated 
data bases. 

863
00:45:13,000 --> 00:45:16,600
Relational databases setting up 
replication and making sure 

864
00:45:16,600 --> 00:45:20,300
replication works properly. 
All of, that is extract stuff. 

865
00:45:20,300 --> 00:45:22,500
You took on because you traded 
off. 

866
00:45:22,600 --> 00:45:25,900
Scaling for asset, no plans. 
So when that happens, 

867
00:45:26,200 --> 00:45:29,400
unknowingly you have three did 
something for something else and

868
00:45:29,400 --> 00:45:33,100
I am saying make that visible 
for yourself, like, okay, I pick

869
00:45:33,100 --> 00:45:35,100
tacit compliance. 
What did I give up? 

870
00:45:35,100 --> 00:45:38,200
And once you start thinking 
about those terms, it makes a 

871
00:45:38,207 --> 00:45:41,000
lot more sense. 
And someone will say, oh my 

872
00:45:41,000 --> 00:45:44,700
database doesn't have to go 
beyond 50 gigabytes fight like 

873
00:45:44,700 --> 00:45:47,800
that trade-off is perfect for 
you, but if someone saying oh my

874
00:45:47,800 --> 00:45:50,600
business is used across the 
world, I will have billion 

875
00:45:50,600 --> 00:45:54,800
millions and billions of Actions
Rose reads, writes, whatever. 

876
00:45:55,000 --> 00:45:58,400
At that time, we cannot just 
blindly say, oh, I pick asset 

877
00:45:58,400 --> 00:46:02,200
our minds because that comes 
with some very tough choices and

878
00:46:02,700 --> 00:46:04,700
making those visible to 
yourself. 

879
00:46:04,700 --> 00:46:07,300
That's why I was saying the 
clearing, is someone else in 

880
00:46:07,300 --> 00:46:10,300
this time, makes sense, because 
you have your own biases and 

881
00:46:10,300 --> 00:46:15,300
everyone has given, I have so, I
generally say, oh, let's sit and

882
00:46:15,300 --> 00:46:18,600
work together because they will 
expose my vices, which is good. 

883
00:46:19,500 --> 00:46:21,900
Well, I think that's a very 
interesting insights, right? 

884
00:46:21,900 --> 00:46:25,400
So yeah, sometimes we develop, 
as we tend to have our own bias 

885
00:46:25,400 --> 00:46:28,600
and we tend to think of the 
problem, may be from limited 

886
00:46:28,600 --> 00:46:31,600
perspective, right? 
So having other people, giving 

887
00:46:31,600 --> 00:46:34,900
the same thought process may be 
from different perspectives, 

888
00:46:35,200 --> 00:46:38,100
maybe design, review, process or
even pairing whenever you come 

889
00:46:38,100 --> 00:46:40,500
up with this decision at the is 
always important. 

890
00:46:40,800 --> 00:46:43,100
And yeah, like you said, in the 
end, there is always a 

891
00:46:43,100 --> 00:46:45,200
trade-off, like Neil also said 
that, right? 

892
00:46:45,200 --> 00:46:46,900
So architecture is all about 
trade-off. 

893
00:46:47,000 --> 00:46:50,300
So knowing that, when we pick 
something basic, We also may be 

894
00:46:50,300 --> 00:46:53,800
compensated for other aspects, 
which we may not realize, but 

895
00:46:53,800 --> 00:46:56,800
sometimes it happens later on, 
right, which is normally the 

896
00:46:56,800 --> 00:47:00,200
performance scalability issues. 
So, another thing that is 

897
00:47:00,200 --> 00:47:03,800
commonly being discussed in this
data world is we all have 

898
00:47:03,800 --> 00:47:06,200
microservices, right? 
But most of the time, start up 

899
00:47:06,300 --> 00:47:09,400
start with the monolith and then
hence we need to break our 

900
00:47:09,400 --> 00:47:13,100
databases, you know, doing more 
like if illusionary, schema 

901
00:47:13,100 --> 00:47:15,700
changes. 
So, since you wrote this book 

902
00:47:15,700 --> 00:47:18,500
refactoring databases long time 
ago, and I think it's very 

903
00:47:18,500 --> 00:47:20,400
applicable. 
I will be split monolith into 

904
00:47:20,400 --> 00:47:22,500
microservice. 
There will be some of your 

905
00:47:22,500 --> 00:47:25,900
advice here for people who are 
going to Embark or are embarking

906
00:47:25,900 --> 00:47:29,100
on this journey to split their 
so-called giant monolithic 

907
00:47:29,100 --> 00:47:31,400
databases into more multiple 
types. 

908
00:47:31,400 --> 00:47:34,100
So is there any key advice that 
you want to give here? 

909
00:47:34,800 --> 00:47:37,000
Yeah definitely. 
I mean there are a lot of 

910
00:47:37,000 --> 00:47:39,600
stepwise things you should 
probably do I think in the 

911
00:47:39,600 --> 00:47:42,500
software architecture of the 
hard part to do, we put up like 

912
00:47:42,500 --> 00:47:47,300
a five-step process for this. 
The first step is to identify 

913
00:47:47,600 --> 00:47:51,300
what are those boundaries? 
He's being the links, right? 

914
00:47:51,300 --> 00:47:54,200
Like, if you are going to take a
monolithic application and split

915
00:47:54,200 --> 00:47:56,500
it. 
Let's see. 3 for example, say 

916
00:47:56,900 --> 00:47:59,700
then there are probably going to
be three domains of three 

917
00:47:59,700 --> 00:48:03,500
services and then you should 
decide within your papers which 

918
00:48:03,500 --> 00:48:08,500
service owns Which tables. 
So let's assume for Simplicity 

919
00:48:08,500 --> 00:48:10,300
sake. 
They're operating table. 

920
00:48:10,300 --> 00:48:14,500
So each service is going to get 
six tables or maybe some service

921
00:48:14,500 --> 00:48:16,700
gets for some service ks8, 
whatever. 

922
00:48:16,800 --> 00:48:18,900
What are those tables? 
They belong to each one of 

923
00:48:18,900 --> 00:48:19,600
those. 
Right. 

924
00:48:19,600 --> 00:48:23,100
So create a boundary, kind of a 
situation and then once you 

925
00:48:23,100 --> 00:48:27,400
have, that cannot be find, then 
there are Educators here because

926
00:48:27,500 --> 00:48:30,500
one service may be right into 
the table and the other service 

927
00:48:30,500 --> 00:48:33,900
me reading from it. 
So you need to decide who is the

928
00:48:33,900 --> 00:48:36,300
owner of this table so that you 
can clearly see. 

929
00:48:37,300 --> 00:48:41,600
So, first step you can do that. 
And the second step is in the 

930
00:48:41,600 --> 00:48:45,400
same database start, moving 
these Stables owned by service, 

931
00:48:45,400 --> 00:48:49,000
a into service, a is scheme like
many tables. 

932
00:48:49,200 --> 00:48:52,000
Any database products, 
especially relational database 

933
00:48:52,000 --> 00:48:54,500
products. 
The give you the facility to 

934
00:48:54,500 --> 00:48:58,000
move between schemas like you 
can see, outer table moves, 

935
00:48:58,000 --> 00:49:01,300
schemas you can just move it to 
a different schema and it just 

936
00:49:01,300 --> 00:49:02,900
gets allocated to a different 
scheme. 

937
00:49:03,100 --> 00:49:06,200
So you are logically segregating
not physical situation. 

938
00:49:06,500 --> 00:49:08,200
Yeah. 
And the monolith is still 

939
00:49:08,200 --> 00:49:11,700
talking to all of them, probably
you will have to do some kind of

940
00:49:11,700 --> 00:49:15,500
a synonym or something so that 
the underlying movement is 

941
00:49:15,500 --> 00:49:17,800
transparent to the application, 
right? 

942
00:49:18,500 --> 00:49:22,000
So once you have On that you're 
physically separated the tables.

943
00:49:22,300 --> 00:49:25,700
But the application is still 
talking to one database, schemas

944
00:49:25,700 --> 00:49:27,200
wire synonyms or something like 
that. 

945
00:49:28,100 --> 00:49:31,900
So this is where now, you start 
to work on the application side,

946
00:49:32,200 --> 00:49:34,900
say, okay. 
Now all of these tables, this 

947
00:49:34,900 --> 00:49:36,700
part of the code is talking to 
that. 

948
00:49:37,000 --> 00:49:40,300
So maybe we should create a 
separate connection pool for 

949
00:49:40,300 --> 00:49:43,600
that or maybe create a separate 
thing for that, that is talking 

950
00:49:43,600 --> 00:49:47,900
directly to that once and you do
that on the application side and

951
00:49:47,900 --> 00:49:50,400
your deploy. 
Make sure everything's working 

952
00:49:50,700 --> 00:49:54,200
and throughout this journey, our
goal is always to iteratively 

953
00:49:54,200 --> 00:49:56,800
keep work, right? 
It shouldn't be that you do all 

954
00:49:56,800 --> 00:50:00,300
these first five steps and 
deploy once, it's every step you

955
00:50:00,300 --> 00:50:03,200
deploy, every step you deploy. 
The because something was wrong 

956
00:50:03,200 --> 00:50:07,300
rollback is he's so Second Step.
You do though, it's tough and 

957
00:50:07,300 --> 00:50:09,600
third step. 
What you do is now that you have

958
00:50:09,900 --> 00:50:13,900
three schemas in your sample 
application three schemas in the

959
00:50:13,900 --> 00:50:17,400
same database that are 
physically the same place, but 

960
00:50:17,400 --> 00:50:21,000
logically separate, right? 
And the application is 

961
00:50:21,100 --> 00:50:24,500
independently talking to them. 
Some is a is talking to schema a

962
00:50:24,500 --> 00:50:27,400
service, be stopping to schema 
be service, he's talking to 

963
00:50:27,400 --> 00:50:30,000
schema see for all practical 
purposes. 

964
00:50:30,000 --> 00:50:32,100
They are independent. 
The only thing that are 

965
00:50:32,100 --> 00:50:34,600
dependent is on one machine 
because they are all running on 

966
00:50:34,600 --> 00:50:37,000
lunch. 
Okay, so now this is where you 

967
00:50:37,000 --> 00:50:40,800
start bringing in replication, 
give install two other or maybe 

968
00:50:40,800 --> 00:50:44,200
three other databases of the 
same type and replicate schema. 

969
00:50:44,200 --> 00:50:49,500
A to machine a replicate schema,
beat machine, the machine And 

970
00:50:49,500 --> 00:50:51,300
you just set up. 
Replication, don't do anything 

971
00:50:51,300 --> 00:50:55,000
else and then whatever is 
happening on here with rights, 

972
00:50:55,100 --> 00:50:58,000
get replicated to other side. 
And one fine day, you can just 

973
00:50:58,000 --> 00:50:59,600
switch connections to those 
others. 

974
00:51:00,100 --> 00:51:02,900
So now service is talking to 
machine, hey service, be 

975
00:51:02,900 --> 00:51:06,800
stopping to, she be and service,
he's talking to machine, see and

976
00:51:06,800 --> 00:51:09,800
you can get rid of this database
break, the replication get rid 

977
00:51:09,800 --> 00:51:12,900
of this database. 
Now, those become the main 

978
00:51:12,900 --> 00:51:16,000
databases and now they are all 
split into Socrates. 

979
00:51:17,100 --> 00:51:20,600
So it's a five-step process. 
Her some complications in this 

980
00:51:20,600 --> 00:51:24,300
of course especially like I 
said, one service is writing to 

981
00:51:24,308 --> 00:51:27,800
one table and other services 
reading from that vehicle, that 

982
00:51:27,800 --> 00:51:31,100
service now needs to figure out,
where do I get the data from? 

983
00:51:31,100 --> 00:51:32,500
Because it's in a different 
database. 

984
00:51:32,800 --> 00:51:36,500
So you have to create probably 
some API changes to read, don't 

985
00:51:36,500 --> 00:51:39,400
make the service do a cross 
database connection because that

986
00:51:39,400 --> 00:51:40,900
defeats the purpose of 
microphones. 

987
00:51:41,600 --> 00:51:45,800
So you have to expose an API to 
do that and a bunch of that kind

988
00:51:45,800 --> 00:51:49,300
of dependencies will come in, 
but it at least gives you You 

989
00:51:49,300 --> 00:51:52,500
starting path think about this. 
Like, how do I split water 

990
00:51:52,600 --> 00:51:54,600
plants and how do I get to the 
end goal? 

991
00:51:55,100 --> 00:51:58,600
And many a times, what we do is 
you don't split everything at 

992
00:51:58,600 --> 00:52:01,900
one girl, you just take one 
piece of functionality, take it 

993
00:52:01,900 --> 00:52:04,600
out and then do whatever you 
need to be done. 

994
00:52:04,700 --> 00:52:08,200
Just take that one thing out. 
So if you think about this 

995
00:52:08,200 --> 00:52:12,000
monolith and percent is gone out
or different ways, 90% is still 

996
00:52:12,000 --> 00:52:14,400
emotionally and then you think 
about what's the next thing I 

997
00:52:14,400 --> 00:52:17,900
can work on again, business 
value plays a big deal here 

998
00:52:18,300 --> 00:52:22,100
because Within Only the reason 
to split generally is because of

999
00:52:22,200 --> 00:52:26,100
Architectural Components, like, 
scalability auditability 

1000
00:52:26,100 --> 00:52:29,900
deployability, bunch of those 
kinds of stuff is being hindered

1001
00:52:29,900 --> 00:52:33,300
because of a male. 
That's why you want to split and

1002
00:52:33,300 --> 00:52:35,700
scaling is the only problem 
you're trying to solve. 

1003
00:52:36,000 --> 00:52:37,800
You take one or two of these 
out. 

1004
00:52:37,900 --> 00:52:40,300
The rest of the application is 
fine because it doesn't have 

1005
00:52:40,300 --> 00:52:43,200
that much load. 
The to that you took out has a 

1006
00:52:43,200 --> 00:52:46,400
lot of loader and you can scale 
them out and whatever you 

1007
00:52:46,400 --> 00:52:48,800
probably don't need to split the
rest of the 81st. 

1008
00:52:49,200 --> 00:52:51,700
So you have to think about it 
this way, what is it that I want

1009
00:52:51,700 --> 00:52:55,800
to split first, split it out and
then do I still need to split 

1010
00:52:55,800 --> 00:52:57,000
more? 
Okay. 

1011
00:52:57,000 --> 00:52:58,500
Then what is it that I need to 
speak? 

1012
00:52:58,500 --> 00:53:01,200
Next does the remaining needs to
be split if the answer is? 

1013
00:53:01,200 --> 00:53:04,800
Yes, keep going down that path. 
The answer is no just stop stop 

1014
00:53:04,800 --> 00:53:06,500
right there because you don't 
need to split it. 

1015
00:53:06,900 --> 00:53:10,100
So I generally tend to think 
about it, like, did I achieve 

1016
00:53:10,100 --> 00:53:12,800
what I wanted to achieve the 
eligibility, requirement 

1017
00:53:12,800 --> 00:53:15,500
irritability, whatever it is, 
that you are trying to fix. 

1018
00:53:16,300 --> 00:53:20,600
Once that speaks you can stop 
splitting I think in the 

1019
00:53:20,600 --> 00:53:23,500
application software worked, it 
is also known as the Strangler 

1020
00:53:23,500 --> 00:53:25,200
pattern, right? 
Yes, exactly. 

1021
00:53:25,200 --> 00:53:28,200
I think that was written maybe 
around 2008 or something. 

1022
00:53:28,700 --> 00:53:30,900
Yeah. 
And I think your advice here, 

1023
00:53:31,000 --> 00:53:34,300
don't do it in one go because 
sometimes we want to do it in 

1024
00:53:34,300 --> 00:53:36,000
one go because we feel it's 
risky. 

1025
00:53:36,000 --> 00:53:38,600
And we don't want to deal with 
this kind of work because it 

1026
00:53:38,600 --> 00:53:41,600
tends to be quite long right. 
Whenever we want to evolve our 

1027
00:53:41,600 --> 00:53:43,000
database, schema. 
Right. 

1028
00:53:43,200 --> 00:53:44,800
So I think don't do it in one 
go. 

1029
00:53:44,800 --> 00:53:47,800
Do it iteratively right? 
Know what's the target as well, 

1030
00:53:47,800 --> 00:53:50,800
like what you said? 
So maybe we don't need to split 

1031
00:53:50,800 --> 00:53:52,500
everything in two different 
databases. 

1032
00:53:52,500 --> 00:53:54,500
Some could still exist in the 
model. 

1033
00:53:54,500 --> 00:53:57,200
It as long as you have the 
proper boundaries and you define

1034
00:53:57,200 --> 00:54:00,000
the ownership really well, while
some may be different quality 

1035
00:54:00,000 --> 00:54:03,300
attributes, require you to 
actually split them and hence 

1036
00:54:03,300 --> 00:54:07,100
yeah, you can do this migration.
And I think all your books here 

1037
00:54:07,300 --> 00:54:09,300
have the recipes. 
I would say, the software 

1038
00:54:09,300 --> 00:54:11,600
architecture, the hard part, I 
think like you mentioned, there 

1039
00:54:11,600 --> 00:54:15,100
are five steps you can think of 
how you deal with this splitting

1040
00:54:15,100 --> 00:54:18,700
of databases and whenever we 
deal with eventual consistency 

1041
00:54:18,700 --> 00:54:20,800
and The transaction is also 
covered there. 

1042
00:54:21,400 --> 00:54:25,100
And eventually also, if you deal
with rdbms and you need to 

1043
00:54:25,100 --> 00:54:27,700
evolve your schema, we can 
always go back to your classic 

1044
00:54:27,700 --> 00:54:30,500
book, refactoring, databases, 
where you can have splitting 

1045
00:54:30,500 --> 00:54:32,800
column, renaming columns and 
things like that. 

1046
00:54:32,800 --> 00:54:35,300
There are 70 patterns that you 
mentioned in the beginning. 

1047
00:54:35,900 --> 00:54:38,400
So I think for people here who 
are dealing with all this data 

1048
00:54:38,400 --> 00:54:42,400
Journey, please do check out 
promotes resources books, right?

1049
00:54:42,700 --> 00:54:46,000
And also lately about data 
measure, I also had an episode 

1050
00:54:46,000 --> 00:54:47,900
with drama. 
I think it's also becoming 

1051
00:54:47,900 --> 00:54:50,500
trendy especially me. 
Missing the operational and 

1052
00:54:50,500 --> 00:54:53,500
analytical concerns, and also 
how to get data out of it 

1053
00:54:53,500 --> 00:54:55,900
easily, right? 
So, I think all these definitely

1054
00:54:55,900 --> 00:54:57,900
are some of the trends in the 
data of space. 

1055
00:54:58,200 --> 00:55:00,100
So promote, thank you so much 
for this conversation. 

1056
00:55:00,100 --> 00:55:03,400
I really love and learn a lot 
about how to deal with data 

1057
00:55:03,400 --> 00:55:05,500
better. 
We are reaching the end of our 

1058
00:55:05,500 --> 00:55:08,300
conversation, but I have one 
last question that I normally 

1059
00:55:08,300 --> 00:55:10,800
ask for all my guests, which I 
call the three technical 

1060
00:55:10,800 --> 00:55:12,700
leadership. 
Wisdom, you can think of it, 

1061
00:55:12,707 --> 00:55:16,700
like, an advice for people here 
to learn and listen from you. 

1062
00:55:16,700 --> 00:55:18,200
Right? 
What would be your tree? 

1063
00:55:18,200 --> 00:55:22,000
Technically, the It was them. 
The first one I would say is 

1064
00:55:22,000 --> 00:55:24,800
keep learning new things, 
whatever it is like in your own 

1065
00:55:24,800 --> 00:55:27,900
work area, or it would be 
outside of work or whatever it 

1066
00:55:27,900 --> 00:55:29,500
is. 
Keep learning new things. 

1067
00:55:30,000 --> 00:55:32,700
The second is, make sure you're 
mentoring. 

1068
00:55:32,700 --> 00:55:36,400
Someone always could be other 
developers, it would be the data

1069
00:55:36,400 --> 00:55:38,200
people, it could be someone 
outside. 

1070
00:55:38,200 --> 00:55:41,800
Make sure you're always 
mentoring others and I have 

1071
00:55:41,800 --> 00:55:44,800
found that mentoring others, 
gives me New Perspectives on 

1072
00:55:44,800 --> 00:55:48,500
things because I may be telling 
them things, but I'm learning a 

1073
00:55:48,508 --> 00:55:49,200
lot. 
Why? 

1074
00:55:49,200 --> 00:55:51,300
I think I find that really 
interesting. 

1075
00:55:51,800 --> 00:55:57,700
I do enjoy mentoring. 
The third is always, I have said

1076
00:55:57,700 --> 00:56:00,100
this problem with three times 
already, this, whatever 

1077
00:56:00,100 --> 00:56:03,800
decisions you're making involve 
the business because it has cost

1078
00:56:03,800 --> 00:56:06,800
implications. 
And as technology people, I 

1079
00:56:06,800 --> 00:56:09,300
don't think we can decide on 
cost. 

1080
00:56:09,600 --> 00:56:14,400
It is businesses decision to 
take and give them the choices. 

1081
00:56:14,500 --> 00:56:16,800
Because sometimes they don't 
know the choices and they just 

1082
00:56:16,800 --> 00:56:20,400
assume like using big words like
we want asset versus you in 

1083
00:56:20,400 --> 00:56:22,200
terkoz's, they have no idea what
you've done. 

1084
00:56:22,700 --> 00:56:24,200
So give them the choice in the 
show. 

1085
00:56:24,300 --> 00:56:27,600
Oh them like a rubric or show 
them, comparative analysis, show

1086
00:56:27,600 --> 00:56:29,400
them. 
If I choose this, these are the 

1087
00:56:29,400 --> 00:56:33,000
implications. 
If I choose that Nations and 

1088
00:56:33,000 --> 00:56:35,600
here's the cost for a versus 
cost for p. 

1089
00:56:36,900 --> 00:56:39,400
Not pick one. 
Right? 

1090
00:56:39,600 --> 00:56:44,100
Because that gives them, lots of
information on which they can 

1091
00:56:44,300 --> 00:56:47,500
make a decision and it will make
you a better Technologies, 

1092
00:56:47,500 --> 00:56:51,600
because you are thinking as a 
neutral person, giving them both

1093
00:56:51,600 --> 00:56:55,300
choices, right? 
And that forces you to do deep 

1094
00:56:55,300 --> 00:56:58,300
analysis and research, when 
you're putting those two 

1095
00:56:58,300 --> 00:57:00,900
choices. 
If one choice is lots of pros 

1096
00:57:00,900 --> 00:57:02,600
and the other choice is not sub 
cons. 

1097
00:57:03,000 --> 00:57:06,100
Then they know that you 
basically want this and not bad 

1098
00:57:06,600 --> 00:57:08,500
and that makes you focus more 
on. 

1099
00:57:08,600 --> 00:57:11,500
And how do I analyze this? 
How do I make sure there are 

1100
00:57:11,500 --> 00:57:15,800
Pros proper, prozac, both sides,
proper content website so that 

1101
00:57:16,000 --> 00:57:18,200
people can make. 
And I think it makes you a 

1102
00:57:18,207 --> 00:57:21,000
better Technologies when you 
make someone else take the 

1103
00:57:21,000 --> 00:57:23,500
decision and you are giving all 
the information. 

1104
00:57:24,200 --> 00:57:26,900
Wow, I really love that better 
Technologies is not the one who 

1105
00:57:26,900 --> 00:57:29,900
make the decision but actually 
they're giving the people the 

1106
00:57:29,900 --> 00:57:32,800
chance to make the decision 
knowing the well-informed 

1107
00:57:32,800 --> 00:57:35,600
information given by us from 
Technologies things rights. 

1108
00:57:35,600 --> 00:57:38,500
Very, very lovely and also what 
you mentioned sometimes. 

1109
00:57:38,500 --> 00:57:40,400
Yeah. 
Business didn't know what 

1110
00:57:40,400 --> 00:57:42,600
options exist. 
They're all know is just like 

1111
00:57:42,600 --> 00:57:45,500
jargons here joginder and yet 
they will just leave it to 

1112
00:57:45,500 --> 00:57:48,300
developers to decide. 
So I think as developers we have

1113
00:57:48,300 --> 00:57:51,900
to give them the information in 
the may be easily 

1114
00:57:51,900 --> 00:57:54,100
understandable. 
And yeah, decisions should be 

1115
00:57:54,107 --> 00:57:56,000
taken collectively. 
I would say, not just my 

1116
00:57:56,000 --> 00:57:58,100
business also, but also with the
Technologies. 

1117
00:57:59,000 --> 00:58:01,100
What are the implications of the
decision? 

1118
00:58:01,100 --> 00:58:04,200
I think that's where we need to 
be making decisions, probably 

1119
00:58:04,300 --> 00:58:06,800
just toss a coin and make 
decisions but what the 

1120
00:58:06,800 --> 00:58:11,100
implications of the decision 
Downstream our rate of X is the 

1121
00:58:11,100 --> 00:58:12,500
key part. 
Yeah. 

1122
00:58:12,500 --> 00:58:14,300
Correct. 
So implications is always 

1123
00:58:14,300 --> 00:58:17,300
something that we regret 
whenever we reach that stage. 

1124
00:58:17,700 --> 00:58:19,900
So I think you're the 
implication should be well, 

1125
00:58:19,900 --> 00:58:21,700
thought out and discussed in the
beginning. 

1126
00:58:22,400 --> 00:58:25,600
So promote, if people would love
to continue the conversation 

1127
00:58:25,600 --> 00:58:28,200
here, would like to ask you a 
reach out to you asking about 

1128
00:58:28,200 --> 00:58:30,900
data related stuffs, is there a 
place where they can reach out 

1129
00:58:30,900 --> 00:58:34,700
and contact you online? 
Yeah I do have a Twitter handle.

1130
00:58:34,700 --> 00:58:37,300
Its promotes analogous at 
promotes evaluate. 

1131
00:58:37,800 --> 00:58:40,700
I do also. 
In a website this is not a.com 

1132
00:58:41,200 --> 00:58:45,300
so you can reach out to me from 
there and kind of like very easy

1133
00:58:45,300 --> 00:58:49,500
to spot me on Twitter and 
Linkedin my website. 

1134
00:58:49,500 --> 00:58:52,900
So any of those forms are fine 
and I generally tend to reply 

1135
00:58:52,900 --> 00:58:56,600
because I am super interesting 
data and its effects on people. 

1136
00:58:57,200 --> 00:58:58,500
All right, thank you so much for
your time. 

1137
00:58:58,500 --> 00:59:02,000
I really love our conversation. 
And again, I hope people here 

1138
00:59:02,000 --> 00:59:05,300
are much well-educated about 
dealing with data and doesn't 

1139
00:59:05,300 --> 00:59:06,800
think it's a hard problem 
anymore. 

1140
00:59:07,000 --> 00:59:08,300
So, thanks again. 
Promote. 

1141
00:59:08,700 --> 00:59:10,900
Thank you, and we thank you for 
this time and thank you very 

1142
00:59:10,900 --> 00:59:15,900
much. 
Thank you for listening to this 

1143
00:59:15,900 --> 00:59:19,300
episode and for staying, right 
until the end if you highly 

1144
00:59:19,300 --> 00:59:21,700
enjoyed it. 
I would appreciate if you share 

1145
00:59:21,700 --> 00:59:24,100
it with your friends and 
colleagues who you think would 

1146
00:59:24,100 --> 00:59:26,500
also benefit from listening to 
this episode. 

1147
00:59:26,800 --> 00:59:29,500
And if you are new to the 
podcast, make sure to subscribe 

1148
00:59:29,500 --> 00:59:32,000
and leave me your valuable 
review and feedback. 

1149
00:59:32,300 --> 00:59:35,200
It helps me a lot in order to 
grow this podcast better. 

1150
00:59:35,600 --> 00:59:38,500
You can also find the full show 
notes of this conversation on 

1151
00:59:38,500 --> 00:59:42,600
the episode page, at Tech Legion
o.f website, including the full 

1152
00:59:42,600 --> 00:59:45,500
transcript interesting. 
Quartz and links to the 

1153
00:59:45,500 --> 00:59:47,900
resources mention from the 
conversation. 

1154
00:59:48,200 --> 00:59:51,300
And lastly, make sure to 
subscribe to the shows mailing 

1155
00:59:51,300 --> 00:59:54,700
list on pack leader. 
No dot f to get notified for any

1156
00:59:54,700 --> 00:59:57,400
future episodes. 
Stay tuned for the next 

1157
00:59:57,400 --> 00:59:58,700
technology. 
No episode. 

1158
00:59:59,100 --> 01:00:00,700
And until then goodbye.