00:00 - 00:04
hey everyone today we explore the design
00:02 - 00:06
of a global payment system much like
00:04 - 00:09
PayPal that handles high transaction
00:06 - 00:11
volumes and sells both merchants and
00:09 - 00:13
consumers worldwide I'll walk through
00:11 - 00:15
each step of the design discuss how
00:13 - 00:17
various components interact and analyze
00:15 - 00:19
the trade-offs involved in making key
00:17 - 00:21
architectural decisions this is
00:19 - 00:23
especially relevant for those preparing
00:21 - 00:26
for system design interviews at leading
00:23 - 00:29
te companies like meta or Google so
00:26 - 00:29
let's get started
00:31 - 00:36
before diving into the system design
00:33 - 00:38
let's quickly clarify two key components
00:36 - 00:39
the payment Gateway and the payment
00:38 - 00:42
processor which I have previously
00:39 - 00:43
explained in depth but at a high level
00:42 - 00:45
think of payment Gateway as the bridge
00:43 - 00:48
between the user's device and the
00:45 - 00:49
payment processor it securely transits
00:48 - 00:52
payment data from the user's device to
00:49 - 00:54
the processor handling the encryption
00:52 - 00:56
and authorization of the transaction for
00:54 - 00:58
example when you enter your car details
00:56 - 01:00
on a website the payment Gateway
00:58 - 01:02
encrypts this data and send it for
01:00 - 01:04
approval and once the payment data
01:02 - 01:06
reaches the payment processor it
01:04 - 01:09
communicates with the users's bank or
01:06 - 01:11
card Network like Visa or MasterCard to
01:09 - 01:13
validate the payment information it
01:11 - 01:15
confirms available funds and completes
01:13 - 01:17
the transaction it's the engine working
01:15 - 01:19
behind the scenes to ensure the money
01:17 - 01:20
flows from the users Bank to the
01:19 - 01:23
Merchant's
01:20 - 01:25
account now first and foremost let's
01:23 - 01:27
clarify the requirements to ensure we
01:25 - 01:29
are all on the same page here we are
01:27 - 01:31
designing a global payment system at
01:29 - 01:34
accessible to users worldwide both
01:31 - 01:36
merchants and consumers are our primary
01:34 - 01:39
users and the system supports onetime
01:36 - 01:42
payments recurring payments refunds and
01:39 - 01:44
dispute resolutions it can also handle
01:42 - 01:46
multiple currencies with real-time
01:44 - 01:49
exchange rates the system should scale
01:46 - 01:51
to handle transaction volumes similar to
01:49 - 01:53
PayPal which means thousands of
01:51 - 01:55
transactions per second it must also
01:53 - 01:58
meet International and Regional
01:55 - 02:00
regulations like PCI DSS and kyc
01:58 - 02:02
requirements as far as nonfunctional
02:00 - 02:05
requirements are concerned it should
02:02 - 02:08
display High reliability scalability low
02:05 - 02:09
latency and topnotch
02:08 - 02:11
security understanding these
02:09 - 02:13
requirements And discussing them with
02:11 - 02:15
the interviewer will set the foundation
02:13 - 02:16
of your design now our system goals
02:15 - 02:18
should align closely with the
02:16 - 02:20
requirements so when we talk about high
02:18 - 02:24
availability aim for
02:20 - 02:26
99.99% uptime it should be efficiently
02:24 - 02:27
able to handle Peak loads and grow with
02:27 - 02:30
demand it should Implement robust
02:29 - 02:33
measures to protect data and
02:30 - 02:35
transactions ensure quick and seamless
02:33 - 02:37
transaction processing and you must
02:35 - 02:38
design the system to easily add new
02:37 - 02:41
features or support additional
02:38 - 02:43
currencies and payment methods with
02:41 - 02:45
these goals in mind we can start
02:43 - 02:46
architecting the system all right we'll
02:45 - 02:49
first break down the architecture of a
02:46 - 02:51
high performance payment system focusing
02:49 - 02:54
on three key layers the client layer the
02:51 - 02:56
service layer and the data layer first
02:54 - 02:58
the client layer this is where users
02:56 - 03:01
interact with the system through web
02:58 - 03:03
apps mobile apps or apis it is
03:01 - 03:05
responsible for sending requests like
03:03 - 03:08
login or payment initiation to the
03:05 - 03:10
backend next we have the service layer
03:08 - 03:12
this is the heart of the system here
03:10 - 03:15
various microservices handle business
03:12 - 03:17
logic like verifying account balances
03:15 - 03:20
processing payments and interacting with
03:17 - 03:21
external gateways these Services
03:20 - 03:23
communicate asynchronously through
03:21 - 03:26
message Brokers like Kafka ensuring
03:23 - 03:28
scalability and fall tolerance and
03:26 - 03:30
finally the data layer this is where all
03:28 - 03:32
the important data is stored relational
03:30 - 03:35
databases handle transactional data no
03:32 - 03:37
SQL systems manage session data and logs
03:35 - 03:39
and caches like redis store frequently
03:37 - 03:42
access information for fast
03:39 - 03:44
responses together these three layers
03:42 - 03:46
will ensure the system is scalable
03:44 - 03:48
reliable and high performing let's start
03:46 - 03:50
with the client layer the client layer
03:48 - 03:51
is the front-facing part of the system
03:50 - 03:54
that interacts directly with the end
03:51 - 03:56
users both consumers and Merchants this
03:54 - 03:58
Slayer is responsible for user
03:56 - 04:01
interfaces and making requests to the
03:58 - 04:03
backend services it can include web
04:01 - 04:05
applications or web portals where users
04:03 - 04:07
can login manage accounts and make
04:05 - 04:10
payments Etc it can also have mobile
04:07 - 04:13
apps iOS or Android used by customers to
04:10 - 04:15
initiate payments check balances and so
04:13 - 04:17
on and so forth and finally the API
04:15 - 04:19
consumers the third party systems or
04:17 - 04:22
Services interacting with the payment
04:19 - 04:24
system via apis for example Merchants
04:22 - 04:26
integrating payments into their own
04:24 - 04:28
websites next the service layer is the
04:26 - 04:30
core of the system that contains all the
04:28 - 04:32
business logic and microservice is
04:30 - 04:34
responsible for processing user request
04:32 - 04:36
handling payments managing users and
04:34 - 04:38
more this layer is the brain of the
04:36 - 04:41
architecture where various microservices
04:38 - 04:44
interact data is validated and external
04:41 - 04:46
systems are called now again a payment
04:44 - 04:48
Gateway is the service responsible for
04:46 - 04:51
securely transmitting payment data from
04:48 - 04:53
the customer for example a web or mobile
04:51 - 04:55
app to the payment processor or bank it
04:53 - 04:58
handles tasks like encryption of the
04:55 - 04:59
payment for example the card details
04:58 - 05:02
authorization of the transaction with
04:59 - 05:04
the issuing bank or card Network fraud
05:02 - 05:05
deduction such as doing initial checks
05:04 - 05:08
or routing the request to the payment
05:05 - 05:10
processor in our design we will use
05:08 - 05:12
Amazon API Gateway as the entry point
05:10 - 05:14
for all request we will later combine it
05:12 - 05:16
with payment service and possibly parts
05:14 - 05:19
of the fraud detection service to play
05:16 - 05:21
the role of the payment Gateway these
05:19 - 05:23
components securely transfit the payment
05:21 - 05:26
data and interact with external payment
05:23 - 05:28
processor or Banks it's also responsible
05:26 - 05:31
for rate limiting request routing and
05:28 - 05:33
user Authentication making it General
05:31 - 05:34
Gateway for all API requests a payment
05:33 - 05:36
processor is the engine behind the
05:34 - 05:38
scenes that processes the actual payment
05:36 - 05:39
after receiving the data from the
05:38 - 05:42
Gateway it communicates with card
05:39 - 05:44
networks such as Visa or Mastercard
05:42 - 05:46
Banks both the issuing and the acquiring
05:44 - 05:49
bank and it also handles the financial
05:46 - 05:51
transactions including authorization
05:49 - 05:55
capturing funds or settling the payments
05:51 - 05:56
Etc in our design the payment service
05:55 - 05:58
account service and the transaction
05:56 - 06:00
service are performing the role of the
05:58 - 06:02
payment processor they verify user
06:00 - 06:04
balances initiate the transaction and
06:02 - 06:06
interact with banks or external payment
06:04 - 06:08
gateways they also handle currency
06:06 - 06:10
conversions they record the transaction
06:08 - 06:12
via the transaction service and update
06:10 - 06:14
the account balance via the account
06:12 - 06:16
service and of course they must ensure
06:14 - 06:19
asset compliance and manage distributed
06:16 - 06:21
transactions across services so at a
06:19 - 06:23
high level we are dealing with
06:21 - 06:25
distributed microservices architecture
06:23 - 06:28
this is the code logic where services
06:25 - 06:29
like user service payment account and
06:28 - 06:32
fraud detection service interact to
06:29 - 06:34
handle payments at scale user service is
06:32 - 06:37
responsible for user authentication and
06:34 - 06:38
profile management payment service
06:37 - 06:40
manages transaction processing and
06:38 - 06:42
external Communications with payment
06:40 - 06:44
gateways and Banks account service
06:42 - 06:47
tracks user balances in multiple
06:44 - 06:49
currencies and ensure Integrity during
06:47 - 06:50
transactions fraud detection service
06:49 - 06:53
performs real-time monitoring of
06:50 - 06:55
transactions to Flat potential frauds
06:53 - 06:57
using machine learning models and
06:55 - 07:00
notification service sends transaction
06:57 - 07:02
updates to users the service interact
07:00 - 07:04
asynchronously through message cues for
07:02 - 07:07
example Kafka rabbit mq for Reliable
07:04 - 07:09
communication and to decouple Services
07:07 - 07:10
we will later dive into how the services
07:09 - 07:13
themselves interact among each other but
07:10 - 07:15
first let's talk about data layer data
07:13 - 07:17
layer consists of relational databases
07:15 - 07:20
for transactional data and no SQL for
07:17 - 07:22
fast access of logs or session data we
07:20 - 07:24
use relational databases like post SQL
07:22 - 07:27
for transactional data to ensure asset
07:24 - 07:29
compliance for non-critical data like
07:27 - 07:32
logs and session information we use no
07:29 - 07:35
SQL databases like cassendra or mongod
07:32 - 07:37
TV in a microservices architecture it's
07:35 - 07:39
generally recommended to use database
07:37 - 07:42
per service to ensure loose coupling and
07:39 - 07:44
data Independence each service owns its
07:42 - 07:46
own data and the schema it uses but they
07:44 - 07:48
can communicate through even driven
07:46 - 07:50
mechanisms like Kafka rather than
07:48 - 07:53
sharing databases so user service
07:50 - 07:55
database stores user data and profile
07:53 - 07:57
information including authentication
07:55 - 08:00
details and kyc or know your customer
07:57 - 08:02
status account service database manages
08:00 - 08:05
user account balances across different
08:02 - 08:06
currencies this database ensures asset
08:05 - 08:09
compliance for critical financial data
08:06 - 08:11
payment service database stores metadata
08:09 - 08:13
about payment request such as who
08:11 - 08:16
initiated the request which Merchant it
08:13 - 08:18
is for what currency is being used and
08:16 - 08:20
the current status of the payment
08:18 - 08:22
currency exchange race table is another
08:20 - 08:24
form of metadata that's used when the
08:22 - 08:26
payment involves multiple currencies it
08:24 - 08:28
stores contextual information about the
08:26 - 08:31
exchange rates used at the time of the
08:28 - 08:33
payment request so before a payment is
08:31 - 08:35
processed the payment service records
08:33 - 08:37
metadata about the payment initiation
08:35 - 08:38
such as who initiated the request which
08:37 - 08:41
Merchant what payment method and
08:38 - 08:43
currency and Status during Payment
08:41 - 08:45
Processing the metadata about the
08:43 - 08:47
payment status such as pending is used
08:45 - 08:49
to track whether the payment was
08:47 - 08:51
successful or if it is still retrying if
08:49 - 08:52
currency conversion is needed the
08:51 - 08:54
payment service looks up the exchange
08:52 - 08:56
rate from the currency exchange rat
08:54 - 08:58
table and uses that rate for the
08:56 - 09:01
conversion and after the payment is
08:58 - 09:03
completed the metadata in the payment
09:01 - 09:06
request table is updated to reflect the
09:03 - 09:07
final status success or failed while the
09:06 - 09:10
detailed transaction records are stored
09:07 - 09:12
in the transaction service database
09:10 - 09:15
transaction service database handles all
09:12 - 09:17
transaction records ensuring durability
09:15 - 09:19
and traceability fraud detection service
09:17 - 09:21
database keeps a historical record of
09:19 - 09:23
flag transactions fraud scores and user
09:21 - 09:26
behaviors data which can be later used
09:23 - 09:28
for machine learning models and finally
09:26 - 09:30
notification service database TOS
09:28 - 09:32
notification log for tracking whether
09:30 - 09:34
payment confirmation messages like
09:32 - 09:37
emails SMS push notifications were sent
09:34 - 09:39
successfully now to handle massive data
09:37 - 09:40
sets and high read write operations you
09:39 - 09:43
should mention few things during the
09:40 - 09:45
interview Shing we partition the
09:43 - 09:47
database horizontally based on user IDs
09:47 - 09:52
regions we have read replicas to improve
09:49 - 09:54
read performance and provide redundancy
09:52 - 09:56
also talk about indexing frequently
09:54 - 09:58
queried fields to speed up database
09:56 - 10:01
operations I have made videos on each of
09:58 - 10:03
these topics in depth so do check them
10:01 - 10:06
out to get better clarity now let's jump
10:03 - 10:08
into the data in the no SQL database
10:06 - 10:10
session data typically includes details
10:08 - 10:12
about user login session tokens time
10:10 - 10:15
stamps and expiration times which can be
10:12 - 10:17
stored in a nosql database event logs
10:15 - 10:19
capture actions taken by users or
10:17 - 10:22
systems events for example logins
10:19 - 10:24
payments or password changes and they
10:22 - 10:26
need to be stored efficiently to support
10:24 - 10:28
high right throughput which also can be
10:26 - 10:30
stored in a nosql database now for each
10:28 - 10:33
key interaction between services will be
10:30 - 10:35
using Kafka qes or Kafka topics which
10:33 - 10:37
ensure asynchronous communication and
10:35 - 10:39
decoupling here's the list of Kafka
10:37 - 10:42
topics that might be in play based on
10:39 - 10:44
the described architecture so for
10:42 - 10:46
example we'll have balance check Q which
10:44 - 10:48
takes request from payment service to
10:46 - 10:50
account service for balance verification
10:48 - 10:51
balance response queue from account
10:50 - 10:54
service response with balance
10:51 - 10:55
verification result transaction
10:54 - 10:57
recording Quee for payment service
10:55 - 11:00
notifying transaction service to
10:57 - 11:02
purchase transaction data account update
11:00 - 11:05
que for notification for account service
11:02 - 11:07
to update the users balance notification
11:05 - 11:09
Q is for message to notification service
11:07 - 11:11
to send a confirmation to the users
11:09 - 11:14
fraud detection que is for transaction
11:11 - 11:16
details sent for realtime fraud analysis
11:14 - 11:18
payment Gateway queue for asynchronous
11:16 - 11:21
communication with external payment
11:18 - 11:22
gateways and Gateway response queue
11:21 - 11:24
which is responsible for response from
11:22 - 11:26
external Gateway back to the payment
11:24 - 11:28
service now this being a microservices
11:26 - 11:30
architecture we are using one of the
11:28 - 11:32
popular data database per service
11:30 - 11:35
microservices pattern so as far as
11:32 - 11:37
database ownership is concerned user
11:35 - 11:39
service owns the user database for user
11:37 - 11:41
profiles and authentication account
11:39 - 11:44
service owns the account database for
11:41 - 11:46
account balances and currency handling
11:44 - 11:48
payment service owns its own payment
11:46 - 11:50
meta database for logging payment
11:48 - 11:51
request transaction service owns the
11:50 - 11:54
transaction database for storing
11:51 - 11:56
transaction records fraud detection
11:54 - 11:58
service owns its own fraud detection
11:56 - 12:00
database for storing fraud logs and user
11:58 - 12:02
risk profiles
12:00 - 12:04
notification service owns its own
12:02 - 12:06
notification log database for storing
12:04 - 12:08
notification history all right now that
12:06 - 12:10
we have laid out all the components and
12:08 - 12:12
Basics let's explore the service layer
12:10 - 12:15
and how these all components interact
12:12 - 12:17
during a typical transaction flow so the
12:15 - 12:19
user initiates the login process from a
12:17 - 12:20
web or mobile app by sending credentials
12:20 - 12:25
Gateway the API Gateway sits behind a
12:23 - 12:27
load balancer which distributes the
12:25 - 12:29
incoming request across multiple API
12:27 - 12:32
gateways instances for for high
12:29 - 12:34
availability the API Gateway forwards
12:32 - 12:36
the login request to the user service
12:34 - 12:38
user service validates the user
12:36 - 12:40
credentials against a cach version of
12:38 - 12:42
the user profile in redus to speed up
12:40 - 12:44
authentication and if no cache entry
12:42 - 12:47
exist the user service fetches the user
12:44 - 12:49
data from the user service database if
12:47 - 12:52
the credentials are valid the service
12:49 - 12:54
generates a JWT token and stores session
12:52 - 12:56
related data such as user ID session
12:54 - 12:59
start time Etc and Rees for fast access
12:56 - 13:01
in future request the user service then
12:59 - 13:03
sends the JWT token back to the API
13:01 - 13:06
Gateway which returns it to the client
13:03 - 13:08
the JWT token will be used in subsequent
13:06 - 13:10
request for authorization and if you
13:08 - 13:13
want to know more about how JWT Works do
13:10 - 13:15
check out my video on JWT where have
13:13 - 13:19
explained it in detail with examples all
13:15 - 13:21
right now let's take a common example
13:19 - 13:22
once the user is authenticated
13:21 - 13:25
initiating a
13:22 - 13:27
payment so in this common use case the
13:25 - 13:29
user initiates a payment for example for
13:27 - 13:31
a purchase by sending the payment
13:29 - 13:33
details to the API Gateway the API
13:31 - 13:36
Gateway receives the payment initiation
13:33 - 13:39
request and verifies the jwd token to
13:36 - 13:41
authenticate the user once the user is
13:39 - 13:42
authenticated it forwards the request to
13:41 - 13:44
the payment service for further
13:42 - 13:45
processing the payment service checks
13:44 - 13:48
the red cash again for the users's
13:45 - 13:50
account balance if the balance is cashed
13:48 - 13:52
and sufficient the payment service locks
13:50 - 13:54
the required amount in radies and if the
13:52 - 13:57
balance is not cast or is outdated it
13:54 - 13:59
proceeds with the next step the payment
13:57 - 14:02
service publishes the message que to the
13:59 - 14:03
balance check Kafka Q asking the account
14:02 - 14:05
service to verify the user's account
14:03 - 14:08
balance and the message might include
14:05 - 14:10
user ID payment amount currency or a
14:08 - 14:13
correlation ID to track the request
14:10 - 14:15
response interaction the account service
14:13 - 14:17
listens to the balance check queue and
14:15 - 14:19
retrieves the users's account balance it
14:17 - 14:22
can use radi for the cash balance and if
14:19 - 14:24
not cashed it retrieves the balance from
14:22 - 14:27
post equl if sufficient funds are
14:24 - 14:29
available it updates the cash and locks
14:27 - 14:31
the funds in post SQL using database
14:29 - 14:33
transactions the account service then
14:31 - 14:35
publishes a response message to balance
14:33 - 14:37
response queue with a verification
14:35 - 14:38
result for example balance is sufficient
14:38 - 14:41
insufficient the payment service listens
14:40 - 14:43
for the response message from the
14:41 - 14:45
balance response queue and if funds are
14:43 - 14:47
sufficient it locks the amount and
14:45 - 14:49
proceeds with the payment processing for
14:47 - 14:50
example interacting with the external
14:49 - 14:52
payment Gateway or recording the
14:50 - 14:54
transaction and if funds are
14:52 - 14:57
insufficient the payment service returns
14:54 - 14:59
an error to the user via the API Gateway
14:57 - 15:01
now since PayPal or a similar similar
14:59 - 15:03
service combines both the Gateway and
15:01 - 15:05
processor roles the service layer in our
15:03 - 15:07
architecture implements both so the
15:05 - 15:08
payment Gateway functionality is about
15:07 - 15:11
receiving payment details and securely
15:08 - 15:13
transmitting them and payment process
15:11 - 15:16
functionality is validating and settling
15:13 - 15:18
transactions by interacting with banks
15:16 - 15:20
however PayPal still relies on external
15:18 - 15:23
Financial systems like bank or card
15:20 - 15:25
networks for actual money movement when
15:23 - 15:28
I say card networks it means networks
15:25 - 15:30
like Visa or Mastercard and when I say
15:28 - 15:32
Banks it's for both the merchant and the
15:30 - 15:34
customer to actually move funds this
15:32 - 15:36
Banking and card Network Integrations
15:34 - 15:38
are external from PayPal system and are
15:36 - 15:40
necessary to complete the financial
15:38 - 15:42
transactions do check out my previous
15:40 - 15:44
videos to understand their role better
15:42 - 15:45
all right coming back to the topic the
15:44 - 15:47
payment service many to interact with
15:45 - 15:49
external payment processor like
15:47 - 15:51
Mastercard or VISA to authorize and
15:49 - 15:53
settle the payment it publishes a
15:51 - 15:55
request to the payment Gateway Que in
15:53 - 15:58
Kafka which is processed asynchronously
15:55 - 16:00
to avoid latency for the user once the
15:58 - 16:02
external gate gway for example Visa
16:00 - 16:04
processes the payment it sends a
16:02 - 16:07
response for example payment approved or
16:04 - 16:08
declined VI the Gateway response cue the
16:07 - 16:10
payment service then consumes this
16:08 - 16:12
response and determines the outcome of
16:10 - 16:14
the transaction if the external payment
16:12 - 16:16
Gateway fails to respond the payment
16:14 - 16:18
service implements the retries using an
16:16 - 16:20
exponential backup strategy which I have
16:18 - 16:22
covered in my other videos and if
16:20 - 16:24
repeated failures occur a popular micros
16:22 - 16:26
Services pattern circuit breaker pattern
16:24 - 16:28
prevents overloading the external
16:26 - 16:30
service and once the payment is
16:28 - 16:31
confirmed either synchronously or
16:30 - 16:33
asynchronously the payment service
16:31 - 16:35
notifies the transaction service by
16:33 - 16:37
publishing a message to Kafka the
16:35 - 16:39
transaction service consumes the message
16:37 - 16:41
and purs the transaction details for
16:39 - 16:43
example the transaction ID time stamp
16:41 - 16:46
amount status Etc it ensures that these
16:43 - 16:48
operations adhere to asset properties
16:46 - 16:51
atomicity consistency isolation and
16:48 - 16:53
durability to maintain data Integrity
16:51 - 16:54
the payment service sends an item
16:53 - 16:57
potency key along with the request to
16:54 - 16:58
the transaction service to ensure that
16:57 - 17:00
the retrying of the payment due to
16:58 - 17:02
network or service failures doesn't
17:00 - 17:04
result in duplicate charges of
17:02 - 17:05
transaction the transaction service
17:04 - 17:08
checks the key before committing to the
17:05 - 17:10
transaction to the database and once the
17:08 - 17:12
transaction is successfully recorded the
17:10 - 17:14
payment service sends a message to the
17:12 - 17:16
account update queue in Kafka notifying
17:14 - 17:18
the account service to update the user's
17:16 - 17:20
balance the account service consumes the
17:18 - 17:22
message deducts the payment amount from
17:20 - 17:24
the user balance in the post equal
17:22 - 17:26
database and updates the balance and
17:24 - 17:28
Ries for future transactions after the
17:26 - 17:29
transaction is recorded the payment
17:28 - 17:31
Service public reaches a message to the
17:29 - 17:34
notification Q in Kafka indicating that
17:31 - 17:36
a notification email or SMS should be
17:34 - 17:38
sent to the users the notification
17:36 - 17:41
service consumes the message and sends
17:38 - 17:43
the confirmation via email SMS or push
17:41 - 17:45
notification to the user again
17:43 - 17:47
notifications are sent as synchronously
17:45 - 17:49
to avoid delaying the main payment flow
17:47 - 17:50
also simultaneously as the payment is
17:49 - 17:52
being processed the payment service
17:50 - 17:55
sends transaction data to the fraud
17:52 - 17:56
detection service bya Kafka the fraud
17:55 - 17:58
detection service consumes the message
17:56 - 18:00
and runs machine learning models to flag
17:58 - 18:02
potentially fraudulent transactions if
18:00 - 18:04
the fraud risk score is above a certain
18:02 - 18:06
threshold the fraud detection service
18:04 - 18:08
publishes a message to Kafka to Halt the
18:06 - 18:10
transaction or trigger additional
18:08 - 18:12
verification like multiactor
18:10 - 18:14
authentication if the transaction is
18:12 - 18:16
flagged the system can either roll back
18:14 - 18:19
the transaction using compensating
18:16 - 18:21
transactions or require additional user
18:19 - 18:24
input the payment service then responds
18:21 - 18:25
to the user via the API Gateway once a
18:24 - 18:28
transaction has been processed and
18:25 - 18:29
recorded to the system at this point the
18:28 - 18:31
client received a confirmation along
18:29 - 18:33
with the transaction received for
18:31 - 18:35
example the amount transaction ID and
18:33 - 18:37
time stamp and to minimize the perceived
18:35 - 18:39
latency for the user certain parts of
18:37 - 18:41
the flow like external Payment
18:39 - 18:43
Processing notifications and fraud
18:41 - 18:45
detection happens asynchronously the
18:43 - 18:47
user receives a response once the code
18:45 - 18:49
transaction is processed while this
18:47 - 18:51
background task for example sending
18:49 - 18:54
notifications or flagging fraud continue
18:51 - 18:55
to execute without blocking the response
18:54 - 18:57
to ensure resilience and high
18:55 - 18:58
performance we can Implement a number of
18:57 - 19:01
microservices patterns in our
18:58 - 19:02
architecture and it's very important for
19:01 - 19:04
you to talk about some of the
19:02 - 19:06
architecture patterns during your
19:04 - 19:08
interview now I have made videos on each
19:06 - 19:10
of these patterns where I simplify them
19:08 - 19:11
and if something doesn't make sense I
19:10 - 19:13
encourage you to develop a deep
19:11 - 19:15
understanding of them here I will
19:13 - 19:17
briefly talk about a few important
19:15 - 19:19
patterns in the context of this system
19:17 - 19:20
design circuit record pattern can be
19:19 - 19:22
used for external communication with
19:20 - 19:24
payment gateways or Banks if the
19:22 - 19:27
external service becomes unresponsive or
19:24 - 19:29
returns errors our circuit breaker trips
19:27 - 19:31
to prevent further calls it ensures that
19:29 - 19:33
the system doesn't get overloaded with
19:31 - 19:35
retries once the external service is
19:33 - 19:38
back online the circuit breaker
19:35 - 19:40
resets for item poent operations such as
19:38 - 19:42
interacting with an external payment
19:40 - 19:44
processor retries are triggered in case
19:42 - 19:46
of failures for example timeout or
19:44 - 19:48
network error this ensures eventual
19:46 - 19:49
consistency in operations like
19:48 - 19:51
transaction settlement without
19:49 - 19:53
duplicating operations an item potency
19:51 - 19:56
key ensures that ringer transactions due
19:53 - 19:58
to network failures or Etc won't result
19:56 - 20:00
in a duplicate charge the payment
19:58 - 20:02
service accepts a unique item potency
20:00 - 20:04
key from the client ensuring that
20:02 - 20:05
repeated request with same Key Don't
20:04 - 20:07
trigger multiple
20:05 - 20:09
transactions and for distributed
20:07 - 20:10
transactions across multiple services
20:09 - 20:12
such as payment service account service
20:10 - 20:15
or fraud deduction service a saga
20:12 - 20:17
pattern can be used to ensure eventual
20:15 - 20:19
consistency each service commits its
20:17 - 20:20
local transaction and compensating
20:19 - 20:22
actions are triggered if a failure
20:20 - 20:25
occurs in any part of the chain for
20:22 - 20:27
example refund in case the payment fails
20:25 - 20:29
now security is also a critical aspect
20:27 - 20:31
of any payment system in your interview
20:29 - 20:33
you can talk about encryption such as
20:31 - 20:36
data and Transit where all data is
20:33 - 20:38
encrypted using TLS or data at rest
20:36 - 20:41
where sensitive information in databases
20:38 - 20:43
is always encrypted you can also talk
20:41 - 20:45
about authentication and authorization
20:43 - 20:48
for example you can Implement multiactor
20:45 - 20:50
authentication for users or use role
20:48 - 20:53
based access control or rback to limit
20:50 - 20:55
system access fraud detection we are
20:53 - 20:57
already using for real-time monitoring
20:55 - 20:59
and machine learning models to detect
20:57 - 21:01
suspicious activities
20:59 - 21:02
these measures protect both the users
21:01 - 21:04
and the Integrity of the system and if
21:02 - 21:06
you want to learn in detail about each
21:04 - 21:08
of these Concepts do check out my
21:06 - 21:10
security playlist as we wrap up let's
21:08 - 21:12
think about what it takes to handle
21:10 - 21:14
PayPal like volumes of traffic the key
21:12 - 21:16
to scaling effectively lies in
21:14 - 21:18
optimizing every layer of your
21:16 - 21:20
architecture first microservices
21:18 - 21:21
architecture is crucial because by
21:20 - 21:24
breaking down functionality into smaller
21:21 - 21:26
Services each one can scale horizontally
21:24 - 21:28
based on demand without affecting the
21:26 - 21:30
others next load balancing helps
21:28 - 21:32
distribute incoming traffic across
21:30 - 21:34
multiple servers ensuring no single
21:32 - 21:36
instance gets overwhelmed Global load
21:34 - 21:39
balancers make sure traffic is routed to
21:36 - 21:41
the best performing server then there is
21:39 - 21:43
caching implementing inmemory Solutions
21:41 - 21:45
like radies for frequently Access Data
21:43 - 21:48
this drastically reduces the load on
21:45 - 21:50
your databases speeding up your apps
21:48 - 21:52
performance for tasks that aren't
21:50 - 21:54
critical to main flow asynchronous
21:52 - 21:56
procing with message cues can keep
21:54 - 21:58
things fast and responsive offload these
21:56 - 21:59
jobs without slowing down the user
21:59 - 22:03
finally don't forget database
22:01 - 22:05
optimization use read replicas to handle
22:03 - 22:07
queries that don't need to hit the
22:05 - 22:09
primary database and manage large data
22:07 - 22:11
sets effectively with partitioning and
22:09 - 22:12
charting by tweaking each of these
22:11 - 22:15
layers you can build a system that is
22:12 - 22:16
highly scalable with low latency and
22:15 - 22:21
high through
video to article