DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Microservices With Apache Camel and Quarkus
  • RBAC With API Gateway and Open Policy Agent (OPA)
  • Observability Architecture: Financial Payments Introduction
  • What ChatGPT Needs Is Context

Trending

  • Microservices With Apache Camel and Quarkus
  • RBAC With API Gateway and Open Policy Agent (OPA)
  • Observability Architecture: Financial Payments Introduction
  • What ChatGPT Needs Is Context

Low latency and high frequency message processing

Nishant Chandra user avatar by
Nishant Chandra
·
May. 30, 13 · Interview
Like (0)
Save
Tweet
Share
5.24K Views

Join the DZone community and get the full member experience.

Join For Free

 A retail financial trading platform needs very low latency trade processing - trades have to be processed quickly (20,000+ trades/sec) because the market is moving rapidly. A retail platform adds complexity because it has to do this for lots of people. So the result is more users, with lots of trades, all of which need to be processed quickly. 

Given the shift to multi-core thinking, this kind of demanding performance would naturally suggest an explicitly concurrent programming model. A simple design could be to have multiple threads read messages from a queue, process it and update the database. This requires extensive application and database tuning. Unfortunately, due to context switching, neither desired throughput nor ordered processing can be achieved. 

What if the desired throughput (10-100k / sec) can be achieved without writing difficult to debug concurrent code and performing expensive IO?

Alternative is to perform in-memory processing and this is what we explore here. 

A single threaded processor takes input messages sequentially (in the form of a method invocation), runs business logic on it, and emits output events. It operates entirely in-memory, there is no database or other persistent store. Keeping all data in-memory has two important benefits. Firstly it's fast - there's no database to provide slow IO to access, nor is there any transactional behavior to execute since all the processing is done sequentially. The second advantage is that it simplifies programming - there's no object/relational mapping to do. All the code can be written using Java's object model without having to make any compromises for the mapping to a database.
Note that a single threaded processor alleviates the use of locks and maintains ordered processing.
Using an in-memory structure has an important consequence - what happens if everything crashes? The heart of dealing with this is Event Sourcing - which means that the current state of the processor is entirely derivable by processing the input events. As long as the input event stream is kept in a durable store you can always recreate the current state of the business logic engine by replaying the events. So using replication, the events can be written to a file or database.
Further,  to recover quickly from failure, the system can make snapshots of the processor state and restore from the snapshots at regular intervals. 

Event Sourcing is valuable because it allows the processor to run entirely in-memory, but it has another considerable advantage for diagnostics. If some unexpected behavior occurs, the  sequence of events can be copied to development environment and replayed.

The design discussed here can easily be extended to online gaming, credit card processing or serving banner advertisements by Ad servers. An important point to note here is that for trade processing is strictly ordered (not globally) but not necessary for other use cases.

vertx.io is an interesting project employing single-thread model for asynchronous processing.
Processing

Published at DZone with permission of Nishant Chandra, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Microservices With Apache Camel and Quarkus
  • RBAC With API Gateway and Open Policy Agent (OPA)
  • Observability Architecture: Financial Payments Introduction
  • What ChatGPT Needs Is Context

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: