The document discusses the evolution of application architecture from monolithic systems to event-driven microservices, particularly focusing on how banks like Bank Central Asia are adapting to these changes using platforms like Confluent. It highlights the challenges of traditional REST APIs and messaging queues and advocates for asynchronous, decoupled microservices that allow for scalability and faster feature delivery. Additionally, it outlines the benefits of moving to an event-driven architecture, including real-time data processing and improved customer engagement.

1. Integration 5.0: From REST APIs and
Message Queues, to Event-Driven
Microservices
Fransiscus Kaurrany
EVP, Group Architecture & IT Service Quality, Bank Central Asia
Damien Wong
Vice President, APAC (Asia Pacific & Japan), Confluent

2. Fireside Chat
EVP, Group Architecture
& IT Service Quality
Bank Central Asia
VP, APAC
Confluent

3. Enterprises (especially Banks) are moving from
software users, to becoming software
Faster
application
development &
time to market
Enable teams
to build
independently
Reduce
infrastructure
cost and
complexity
Eliminate
dependencies in
feature delivery
Scale services
with smaller,
agile teams
“In many ways, we see ourselves as a technology company with a banking license.” —
Michael Corbat, Citi CEO

4. Evolution of Monolith
APP APP APP APP
Monolith
Large self contained application
Complex app with highly interdependent parts
Poor developer experience and productivity
Slow feature delivery
Difficult to deploy, impacting other systems
Requires replication of entire application
Microservices
Multiple smaller, single function apps
Independently deployable and upgradable
Built around solving business capabilities
Can be built w/ different programming languages
Scalable and agile = faster feature delivery
Leverages newer development platforms
To Microservices

5. Existing approaches to developing microservices
Messaging Queues
(rabbitMQ, ActiveMQ)
● Message brokers act as a centralized
messaging service through which all
of the microservices communicate
● Brokers handle messaging queueing,
HA, reliable communication between
services
● Messages received in a queue rather
than dropped and processed later
Communication via
HTTP REST API
● Benefits:
○ Simple set up
○ Efficient message delivery
● Synchronous communication
○ Client sends request and waits
for response

6. Challenges with REST
based microservices
Fulfillme
nt service
Stock
service
Order
service
Return
service
Payment
service
UI service
GUI
● Difficult to enforce standards across
services
● Does not scale if servers are
synchronous
● Risky inter-service dependencies
● Services required to maintain state
● Complex management and version
compatibility—slows development
● Requires load balancing

7. Challenges with legacy
messaging queues
Microservice
Producer
Legacy
Messaging
Queue
Queue 1
Queue 2
Microservice
A
Microservice
B
● Extremely difficult to scale
● Lacks message persistence—if
message delivery fails, its
unavailable for replay
● Low throughput and high
latency
● Need prior knowledge of
consumers
● Expensive MQ and mainframe
technology costs
●

8. Fulfillment
service
Stock
service
Order
service
Return
service
Payment
service
UI service
GUI
Why build with
Confluent
● Completely decoupled microservices
● Single standard for
inter-communication
● Maintains version compatibility
● Asynchronous services
development
● State persistent on single platform
for replay
● Distributed and highly scalable
● Process data in flight and real-time
● Deployment flexibility -- on prem, in
cloud, or hybrid
Confluent enables a new class of event driven
microservices

9. Why does it make sense?
Microservices
Distributed
Semi-loose with API versioning
Requires a consistent distributed
system
Synchronous
Event Driven Microservices
Central, synchronized through events
Completely decoupled (Fire and forget)
The streaming platform reduces the
dependencies to external system
Reactive (asynchronous)
State
Coupling
E2E Testing
Execution Model

10. Fireside Chat
EVP, Group Architecture
& IT Service Quality
Bank Central Asia
VP, APAC
Confluent

11. Challenges
● We need to scale faster to meet growing customer demands, so we
need platform that can support it
● System reliability & maintenance challenges
● Customer Engagement was impacted due to performance
● It become a challenge for the team to support various technologies
● BCA is largest bank in ASEAN by
Market Cap.
● Processing average 27 million
transactions per day
● 98% of total transaction services
via Digital Channels
Moving to
Event Driven
Architecture
Use Cases/Solutions
● Monolithic to microservices application transformation
● Modernise architecture for more flexibility & agility to meet
customer needs
● Real time customer notifications and marketing
● Real-time event streaming enables Digital Services to drive
advantage
● Going forward, leveraging AI/ML with Event Streaming Platform for
real time analytics
● Expanded use cases for fraud detection, marketing offers /
promotions & ATM security

12. Integration 5.0
Fransiscus Kaurrany
EVP, Group Architecture & IT Service Quality

13. The
Evo-Revolution
BCA Integration Architecture

14. tech
Proprietary Platform
Proprietary Gateway
std. &
comm.
ISO 8583
Sync
app
ATM and Classic EDC
pro & cons
(+) Less Tightly Couple
(-) Proprietary
Technology
tech
Open Platform
Service Bus
Monolithic
Rule Base Engine
std. & comm.
Web Service (SOAP)
Sync
app
Web and Mobile
Channel
pro & cons
(+) > Less Tightly Couple
(+) Open Standard for FE
tech
Cloud Platform
API GW
Messaging Queue
Microservices
std. &
comm.
REST API
Sync + Async
app
OMNI Channel
Android POS
Digital Branch
pro & cons
(+) >> Less Tightly Couple
(+) Open Standard
(+) Light Conn. < 500K
data
tech
Cloud Platform
API GW
Confluent Kafka
Microservices
std. & comm.
REST API + ISO
20022
Sync + Async
app
NRT Analytics and ML
Fraud Detection System
IoT
pro & cons
(+) Loosely Couple
(+) Open Standard
(+) NRT Parallel Process
(+) Massive Data
5.0
Event-Driven
4.0
API GW & MQ
3.0
EAI/SOA/ESB
tech
Socket
EJB / JCA
Screen Scrapping
std. &
comm.
No single standard
Sync
app
Classic Branch
Application
pro & cons
(-) Tightly Couple
2.0
Switching
1.0
Point to Point
The 5.0
Journey
BCA Integration Architecture

15. The Architecture
From 1.0 to 5.0 Integration
1.0 Point to Point
socket
ISO8583
screen
scraping
2.0 Switching
Base2
4
ATM 3rd
PartyED
C
Core Banking
* All ISO8583 base messaging
3.0
EAI/SOA/ESB
Internet Banking
Other Web App
EAI
* Using SOAP
CICS
Transaction
Gateway
ISO8583
*depend
Mobile Banking

16. The Architecture
From 1.0 to 5.0 Integration, continue
4.0 API Gateway & MQ
Base2
4
Core Banking
Front End
EAI
API
Gateway
MQ
3rd
Party
Kafk
a
BIG
DATA
AI/ML Engine
Applications
5.0 Event-Driven

17. Thank You

18. Interacting
2
Join the Confluent Slack Channel
https://launchpass.com/confluentcommunity
Local meetups
https://www.confluent.io/community/
KafkaSummit 2020
https://kafka-summit.org/