1
00:00:00,110 --> 00:00:02,120
Welcome to the architecture. 
Corner glad to be. 

2
00:00:02,130 --> 00:00:05,000
Here today we're looking at your
notes and articles on keeping 

3
00:00:05,010 --> 00:00:08,860
applications running smoothly, 
specifically digging into Active

4
00:00:08,870 --> 00:00:11,990
Active Patterns. 
Our mission really is to cut 

5
00:00:12,000 --> 00:00:13,770
through some of the complexity 
here. 

6
00:00:13,970 --> 00:00:17,220
We want to arm you with the 
insights you need to build apps 

7
00:00:17,230 --> 00:00:21,140
that stay up even if, say, an 
entire region goes offline. 

8
00:00:21,190 --> 00:00:23,370
Exactly. 
It's sort of the Holy Grail of 

9
00:00:23,380 --> 00:00:26,080
availability, isn't it? 
The idea that a whole region can

10
00:00:26,090 --> 00:00:28,860
have a major problem but for 
your users. 

11
00:00:28,870 --> 00:00:31,280
Nothing changes they. 
Don't even notice, that's the 

12
00:00:31,290 --> 00:00:34,860
benchmark we're aiming for with 
these multi region active active

13
00:00:34,870 --> 00:00:36,420
setups. 
OK, so let's picture it. 

14
00:00:36,530 --> 00:00:40,320
An application, all its bits, 
services, databases, everything 

15
00:00:40,330 --> 00:00:43,440
running in let's say 2 or more 
regions at the same time. 

16
00:00:43,450 --> 00:00:45,680
Yeah. 
What's the first big challenge 

17
00:00:45,690 --> 00:00:47,960
you hit? 
Right away it's name resolution 

18
00:00:47,970 --> 00:00:49,960
getting that flawless. 
You can have your servers 

19
00:00:49,970 --> 00:00:53,360
everywhere, but if your DNS 
setup can't instantly flip users

20
00:00:53,370 --> 00:00:55,460
from a failed region to a 
working 1. 

21
00:00:55,550 --> 00:00:57,460
Well, it's pointless. 
OK, DNS. 

22
00:00:57,730 --> 00:00:58,920
What else? 
Then there's application 

23
00:00:58,930 --> 00:01:01,000
synchronization. 
You need all those application 

24
00:01:01,010 --> 00:01:04,220
instances across all your 
regions to be absolutely 

25
00:01:04,230 --> 00:01:07,600
identical and stay that. 
Way right, So deploying the code

26
00:01:07,650 --> 00:01:10,720
consistently, that's one piece, 
but often the real headache 

27
00:01:10,730 --> 00:01:14,140
isn't it the data? 
Like what happens if people in 

28
00:01:14,150 --> 00:01:17,960
different regions try to write 
to the same database record 

29
00:01:18,010 --> 00:01:21,280
almost simultaneously? 
Precisely data synchronization. 

30
00:01:21,290 --> 00:01:22,960
That's usually the biggest 
challenge. 

31
00:01:23,070 --> 00:01:26,710
You mentioned concurrent rights.
Imagine two people trying to buy

32
00:01:26,720 --> 00:01:29,920
the very last widget in stock 
but from different regions, 

33
00:01:30,490 --> 00:01:33,330
without really careful handling,
end up with race conditions. 

34
00:01:33,340 --> 00:01:35,890
You know, where the timing just 
messes everything up, gives you 

35
00:01:35,900 --> 00:01:38,750
wrong results, the complexity 
there and the cost. 

36
00:01:38,760 --> 00:01:40,930
It just shoots up. 
Which brings up a really 

37
00:01:40,940 --> 00:01:43,530
important question. 
Then, given all that extra 

38
00:01:43,540 --> 00:01:48,830
complexity, the cost is a full 
active active setup always the 

39
00:01:48,840 --> 00:01:50,530
right answer? 
Oh, definitely not. 

40
00:01:50,540 --> 00:01:53,530
No, you absolutely need a 
careful return on investment. 

41
00:01:53,540 --> 00:01:57,370
Check an ROI assessment. 
It's often smarter to apply an 

42
00:01:57,380 --> 00:02:00,810
active active pattern to just a 
part of your application that's.

43
00:02:00,820 --> 00:02:03,900
The really critical. 
Bits exactly the most critical 

44
00:02:03,910 --> 00:02:08,940
components that helps manage the
complexity and keeps the costs 

45
00:02:09,389 --> 00:02:11,780
reasonable. 
It's about being strategic, 

46
00:02:11,830 --> 00:02:14,140
surgical even. 
That makes a lot of sense. 

47
00:02:14,190 --> 00:02:16,260
Yeah. 
OK, so let's maybe walk through 

48
00:02:16,270 --> 00:02:18,960
the main patterns then. 
There are three key ones, right?

49
00:02:18,970 --> 00:02:22,720
First is Read local, write 
global. 

50
00:02:23,050 --> 00:02:26,320
How's that one work? 
So with this one, users read 

51
00:02:26,330 --> 00:02:30,350
data from the closest region to 
them, which is fast, but all the

52
00:02:30,360 --> 00:02:33,320
right operations. 
Every single one gets sent to 1 

53
00:02:33,400 --> 00:02:37,150
single primary global region. 
OK, the beauty of it is 

54
00:02:37,160 --> 00:02:39,930
simplicity, really. 
It naturally avoids those 

55
00:02:39,940 --> 00:02:42,060
difficult race conditions 
because, well, everything's 

56
00:02:42,070 --> 00:02:44,130
being written in one. 
Place simple for consistency. 

57
00:02:44,140 --> 00:02:46,950
Got it. 
But the downside for the user 

58
00:02:46,960 --> 00:02:49,110
must. 
Be latency, Yeah, if you're a 

59
00:02:49,120 --> 00:02:51,950
user who's physically far from 
that one designated right 

60
00:02:51,960 --> 00:02:54,350
region, you're right, operations
will take longer. 

61
00:02:54,360 --> 00:02:56,350
It's noticeable. 
So it's best for apps that 

62
00:02:56,360 --> 00:02:58,030
mostly read data. 
Exactly. 

63
00:02:58,040 --> 00:03:01,470
High read to write ratio and 
where maybe losing a few seconds

64
00:03:01,480 --> 00:03:03,870
of data during replication isn't
catastrophic. 

65
00:03:03,980 --> 00:03:09,330
OK, so if read local, write 
global is simple but potentially

66
00:03:09,340 --> 00:03:12,720
slow for writes, how do we 
improve that write latency? 

67
00:03:13,250 --> 00:03:14,840
That sounds like the next 
pattern. 

68
00:03:15,030 --> 00:03:18,540
Read local, write partitioned. 
Right, so again, reads are 

69
00:03:18,550 --> 00:03:22,020
always local fast. 
But for writes, the application 

70
00:03:22,030 --> 00:03:25,080
itself has logic to decide which
region handles the right. 

71
00:03:25,230 --> 00:03:27,440
It's based on some custom rules 
you define. 

72
00:03:27,530 --> 00:03:29,740
Like what? 
Maybe based on the user's 

73
00:03:29,750 --> 00:03:32,340
profile or perhaps where they 
first started their session. 

74
00:03:32,430 --> 00:03:35,760
Like if you start shopping on an
ecommerce site via Regina, maybe

75
00:03:35,770 --> 00:03:38,890
all your rights for that session
get pinned to region A AH. 

76
00:03:38,940 --> 00:03:41,410
OK, seems more balanced for 
latency then. 

77
00:03:41,420 --> 00:03:44,290
What's the catch with this one? 
Well, you're basically building 

78
00:03:44,300 --> 00:03:47,750
sharding logic, the rules for 
distributing data directly into 

79
00:03:47,760 --> 00:03:50,710
your application code. 
That adds complexity and if the 

80
00:03:50,720 --> 00:03:52,830
region designated for your 
rights goes down. 

81
00:03:52,840 --> 00:03:54,910
You can't update your stuff. 
Exactly. 

82
00:03:54,980 --> 00:03:57,950
You won't be able to modify your
specific data until it recovers.

83
00:03:58,200 --> 00:04:01,050
So this pattern is good for 
latency sensitive apps. 

84
00:04:01,060 --> 00:04:04,140
Maybe with a more even read 
write mix, but you have to 

85
00:04:04,150 --> 00:04:07,640
accept that some user data might
be temporarily read only during 

86
00:04:07,650 --> 00:04:08,940
an outage. 
Alright. 

87
00:04:09,170 --> 00:04:14,990
And the third one Read local, 
write local sounds like the 

88
00:04:15,000 --> 00:04:16,940
dream scenario. 
Low latency for reads and 

89
00:04:16,950 --> 00:04:18,600
writes. 
It is from a latency 

90
00:04:18,610 --> 00:04:21,310
perspective, yes. 
Both reads and writes happen in 

91
00:04:21,320 --> 00:04:24,280
the users local region. 
But there's always a but. 

92
00:04:24,470 --> 00:04:27,860
There's always a, but because 
rights are happening everywhere,

93
00:04:27,870 --> 00:04:31,180
you're almost guaranteed to run 
into race conditions eventually.

94
00:04:31,470 --> 00:04:34,280
Think about a loyalty point 
system. 

95
00:04:34,830 --> 00:04:39,120
A user buys something in region 
A earning points, while maybe a 

96
00:04:39,130 --> 00:04:41,810
refund is processed for them in 
region B, deducting points all 

97
00:04:41,820 --> 00:04:44,660
around the same time. 
Your application has to be smart

98
00:04:44,730 --> 00:04:47,170
enough to reconcile these 
conflicting updates. 

99
00:04:47,180 --> 00:04:49,190
Does one win? 
Do they merge somehow? 

100
00:04:49,200 --> 00:04:50,970
Right, you need conflict 
resolution logic. 

101
00:04:51,040 --> 00:04:54,520
You absolutely do so. 
This pattern best for really 

102
00:04:54,530 --> 00:04:57,410
write heavy applications where 
low latency is paramount, but 

103
00:04:57,420 --> 00:04:59,890
you need to be prepared to 
handle those data conflicts. 

104
00:04:59,900 --> 00:05:01,160
OK. 
So let's make this concrete. 

105
00:05:01,170 --> 00:05:02,790
And you mentioned applying this 
surgically. 

106
00:05:02,800 --> 00:05:06,220
Yeah, how would you do that for,
say, an ecommerce app? 

107
00:05:06,230 --> 00:05:08,130
You would make the whole thing 
active Active. 

108
00:05:08,200 --> 00:05:10,070
Probably not. 
You'd identify the critical 

109
00:05:10,080 --> 00:05:13,810
flows taking new orders that's 
likely core business needs very 

110
00:05:13,820 --> 00:05:15,600
fast recovery. 
So you make that act. 

111
00:05:15,670 --> 00:05:17,170
Active, but maybe not 
everything. 

112
00:05:17,180 --> 00:05:20,460
Else right, fulfilling orders or
maybe updating the product 

113
00:05:20,470 --> 00:05:23,360
catalog. 
Perhaps those can tolerate a few

114
00:05:23,370 --> 00:05:26,180
hours of downtime if a region 
fails depending on the business 

115
00:05:26,190 --> 00:05:28,880
impact. 
So your deployment tools, 

116
00:05:29,150 --> 00:05:32,520
hopefully using infrastructure 
as code, would only deploy that 

117
00:05:32,530 --> 00:05:35,640
critical order taking subset to 
all your active regions. 

118
00:05:35,650 --> 00:05:38,440
And routing, how do users get to
the right place? 

119
00:05:38,510 --> 00:05:42,480
Usually DNS maybe like Route 53 
with health checks directing 

120
00:05:42,490 --> 00:05:44,440
users to their closest healthy 
region. 

121
00:05:44,490 --> 00:05:47,010
Simple and effective. 
And the data sync for that 

122
00:05:47,020 --> 00:05:49,570
ecommerce example orders versus 
catalog. 

123
00:05:49,580 --> 00:05:52,770
Yeah, good question. 
For the sales catalog, updates 

124
00:05:52,780 --> 00:05:55,010
often come from one internal 
source, right? 

125
00:05:55,020 --> 00:05:57,500
So you could use cross region 
replication, just streaming 

126
00:05:57,510 --> 00:06:00,550
those changes out. 
If the source region fails, no 

127
00:06:00,560 --> 00:06:03,790
new updates flow, but the 
existing catalog is readable 

128
00:06:03,800 --> 00:06:04,770
everywhere. 
OK. 

129
00:06:04,780 --> 00:06:07,410
And for the shopping? 
Cart that's more user specific. 

130
00:06:07,460 --> 00:06:10,330
Something like bidirectional 
replication may be using 

131
00:06:10,340 --> 00:06:12,650
Dynamodb. 
Global tables works well. 

132
00:06:13,140 --> 00:06:16,150
Users tend to stick to one 
region for their session, which 

133
00:06:16,160 --> 00:06:20,310
minimizes flashes, and even with
acing replication where there's 

134
00:06:20,320 --> 00:06:24,400
a slight delay, you often use a 
last writer wins strategy to 

135
00:06:24,410 --> 00:06:27,240
sort out consistency when things
recover. 

136
00:06:27,390 --> 00:06:30,220
What really stands out here is 
that this isn't just one team's 

137
00:06:30,230 --> 00:06:32,880
job achieving this high 
availability. 

138
00:06:32,930 --> 00:06:34,840
It's multidisciplinary. 
Totally. 

139
00:06:34,850 --> 00:06:37,290
It seems like it has to start 
with a really solid risk 

140
00:06:37,300 --> 00:06:40,080
assessment, understanding how 
critical each piece of your 

141
00:06:40,090 --> 00:06:42,940
application actually is. 
Absolutely, you need that 

142
00:06:42,950 --> 00:06:46,420
business context. 1st and then 
once you know that, you can pick

143
00:06:46,430 --> 00:06:49,950
the right tool for the job from 
those patterns, read local, 

144
00:06:50,020 --> 00:06:53,910
write global, read local write 
partition or read local, write 

145
00:06:53,920 --> 00:06:55,710
local, applying them 
strategically. 

146
00:06:55,720 --> 00:06:57,750
And if we zoom out for a second,
it connects to the bigger 

147
00:06:57,760 --> 00:07:00,190
picture. 
Yes, active active patterns give

148
00:07:00,200 --> 00:07:03,810
you potentially the fastest 
recovery times possible near 0 

149
00:07:03,820 --> 00:07:06,010
sometimes. 
But that power comes with 

150
00:07:06,020 --> 00:07:08,090
significant complexity and. 
Cost. 

151
00:07:08,100 --> 00:07:09,790
So you need that ROI 
justification. 

152
00:07:09,840 --> 00:07:14,090
Always you need that careful 
strategic assessment for every 

153
00:07:14,100 --> 00:07:17,220
application, maybe even every 
service. 

154
00:07:17,600 --> 00:07:22,100
The real skill, the art perhaps,
is knowing when and where to 

155
00:07:22,110 --> 00:07:26,390
deploy this level of resilience.
Getting it right turns that 

156
00:07:26,400 --> 00:07:30,810
potential chaos of an outage 
into, well, seamless continuity 

157
00:07:30,860 --> 00:07:32,890
for your users. 
A great thought to end on 

158
00:07:33,620 --> 00:07:36,510
turning chaos into continuity. 
You can find more details and 

159
00:07:36,520 --> 00:07:38,800
links related to our discussion 
today in the description. 

160
00:07:38,810 --> 00:07:40,930
Definitely check those. 
Out and for more insights like 

161
00:07:40,940 --> 00:07:43,590
this, please do subscribe. 
It's free to the Architecture 

162
00:07:43,600 --> 00:07:45,650
Corner newsletter. 
You can find it at 

163
00:07:45,720 --> 00:07:48,250
architecturecorner.substack.com.
It's a. 

164
00:07:48,260 --> 00:07:50,510
Great resource. 
Finally, a huge thank you to 

165
00:07:50,520 --> 00:07:53,310
Mario Bittencourt, whose 
excellent work really formed the

166
00:07:53,320 --> 00:07:55,640
basis for this conversation. 
Yes, Thank you, Mario. 

167
00:07:55,710 --> 00:07:57,370
We'll catch you next time on the
architecture corner.