The document discusses extreme transaction processing in a memory-oriented architecture, highlighting its benefits such as fast processing speeds, high throughput, and system reliability without losing simplicity and consistency. It emphasizes a new model that utilizes in-memory computing to handle vast scales of transactions efficiently with minimal latency, outperforming traditional architectures. Real-life use cases demonstrate the practical advantages of this approach in various industries, including e-commerce and finance.

1. EXTREME TRANSACTION PROCESSING IN A
MEMORY-ORIENTED WORLD
GIRISH MUTREJA
See all the presentations from the In-Memory Computing
Summit at http://imcsummit.org

2. THE POWER OF IN-MEMORY COMPUTING
FAST!
SIMPLE
// create a new cart
Cart cart = Cart.create();
...
// add to the application's cart collection
carts.put(cart.getId(), order);
...
// update cart counter
stats.incrementNumCarts();
Memory

3. IN-MEMORY TRANSACTION PROCESSING
FAST!
SIMPLE
// create a new cart
Cart cart = Cart.create();
...
// add to the application's cart collection
carts.put(cart.getId(), order);
...
// update cart counter
stats.incrementNumCarts();
Memory
DURABLE
CONSISTENT

4. EXTREME TRANSACTION PROCESSING
Operate at Memory Speed
Without compromising simplicity, durability, consistency and s
By Using Memory Optimally with the Right Architecture

5. HOW “EXTREME” ARE WE TALKING HERE?
 Scale
 10s of millions of orders in application’s working set
 Scale linearly with the business
 Performance
 100s of thousands of order transactions a second
 Microseconds to low milliseconds processing times
 Reliability
 Zero message or data loss across network, process, machine or data center failures
 Agility
 Write pure Java treating memory as the disk

6. TRADITIONAL TP APPLICATION ARCHITECTURE
Relational Database
Data Tier
(Transactional
State
Reference Data)
Application Tier
(Business Logic)
Messaging
(HTTP, JMS)
 Slow
 Complex
 Does not scale with size or
volume
 Synchronous
 Slow
 Poor Routing
(Choke Point!)
Wrong Scaling
Strategy
Slow
Durable
Consistent
Does Not Scale
Complex

7. LAUNCH DATA INTO MEMORY
Data Tier
(Transactional
State
Reference Data)
Application Tier
(Business Logic)
Messaging
(HTTP, JMS)
 Better but still slower than
memory
 Simpler but still not pure domain
 Does not scale with size
 Synchronous
 Slow
 Poor Routing
(Choke Point!)
Wrong Scaling
Strategy
Slow
Durable
Consistent
Does Not Scale
Complex
In-Memory
Replicated

8. DATA GRAVITY (DATA STRIPING + SMART ROUTING)
Data Tier
(Transactional
State
Reference Data)
Application Tier
(Business Logic)
Messaging
(Publish -
Subscribe)
 Better but still slower than
memory
 Simpler but still not pure domain
 Scales with size and volume
(Choke Point!)
Slow
Durable
Consistent
Scales
Complex
In-Memory Replicated + Partitioned
Smart Routing
(messaging traffic partitioned to align with data partitions)
Processing Swim-lanes

9. WHY STILL SLOW AND COMPLEX
 How Slow?
 Latency
 100s of milliseconds
 Throughput
 Very low with single pipe
 Few 1000s per second with high concurrency
 Why Still Slow?
 Remoting out of process
 Synchronous data management and stabilization
 Concurrent transactions are not cheap!
 Why Complex?
 Transaction Management still in business logic
 Thread management for concurrency (only way to scale)
 Data transformations due to lack of structured data models

10. TAKING IT TO THE NEXT LEVEL
Local Application State
 Application state fully in local memory
 Eliminate Remoting
 Performance
Multi-Agency & Transaction Pipelining
 All interactions with outside world is through messaging
 Inbound messages implicitly demarcate transactions
 Non-blocking stabilization
 Treat outbound messages as state
 Performance
 Consistency
 Simplicity
Single Threaded Business Logic  Eliminate concurrent state management
 Performance
 Simplicity
Structured State
 Support full language data model
 Code truly assumes memory is durable
 Performance
 Simplicity

11. TAKING IT TO THE NEXT LEVEL
Application + Data
Tier
(Business Logic
Transactional State
Reference Data)
Messaging
(Publish -
Subscribe)
Fast
Durable
Consistent
Scales
Simple
In Application Memory Replicated + Partitioned
Smart Routing
(messaging traffic partitioned to align with data partitions)
Processing Swim-lanes
 Operate at memory
speeds
 Plumbing free domain
 Scales with size and
volume
Application State
fully in Local
Memory
Single-Threaded
Dispatch
Pipelined
Stabilization
Pure
domain
code

12. NOW WHAT IS THE PERFORMANCE?
 How Fast?
 Latency
 100s of microseconds to low milliseconds
 Throughput
 100s of thousands of transactions per second
 Any issues?
 Jittery due to GC
 Still some work is needed for ultra-low latency

13. TAKING IT EXTREME
Eliminate Inter-Tier Transformations  Zero buffer copies between network and business logic
Eliminate Garbage  Object pre-allocation and recycling
 How Fast?
 Latency
 10s of microseconds
 No jitter
 Throughput
 100s of thousands of transactions per second

14. REAL LIFE USE CASES
 MGM Resorts International
 eCommerce Engine is authored on the X Platform
 10 services/26 agents comprise the eCommerce service suite
 Key metrics
 All state, reference and transactional fully in-memory: ~1TB of in-memory state
 Low 10s of millisecond catalogue/pricing update latency
 500ms (max) full 14 month dynamic pricing response time to website at upwards of 20tps
 Sub-second rate update to partner
 SSO storage engine authored on the X Platform
 Authored as a distributed, persistent, partitioned hash map
 Authored on X in 3 hours!
 <10ms response times @ 20k updates per second
 Bottleneck in messaging bus, X has plenty of more capacity

15. REAL LIFE USE CASES
 Tier 1 Investment Bank Wall Street
 X Platform foundation for all equities applications
 Key Metrics
 Application 1: 50-100k/sec sustained throughput
 Application 2: <100us client-market latency

16. IOT APPLICATION – EXTREME GEOFENCING
Location Event
Processors Intelligent Rule
Execution
Location Events
Mobile Vehicle Pool
Inferences
Decisions
Notifications
Performance
 400k
Transactions/sec
 1.7ms response time
 < 100 lines of code
 1 CPU Socket!
 Stock Hardware
Single Shard!

17. QUESTIONS
?