Introduction
Overview
Rumi is a high-performance microservices platform designed for building ultra-low latency, fault-tolerant distributed systems. This section provides a comprehensive understanding of Rumi's core concepts, architectural patterns, and operational models.
Understanding these concepts is essential for:
Architects designing Rumi-based systems
Developers building Rumi microservices
Operators managing Rumi deployments
Technical decision-makers evaluating Rumi for their use cases
What You'll Learn
This section covers the foundational concepts and architectural patterns that underpin the entire Rumi platform. Each topic builds on the others to provide a complete mental model of how Rumi works.
Core Architecture
Messaging Model - How microservices communicate
Rumi's messaging abstraction provides a unified interface for message exchange across different messaging backbones (Solace, JMS, etc.). Learn how:
Messages are modeled as strongly-typed POJOs
Channel subscriptions and message routing work
Different messaging bindings integrate with the platform
Message delivery guarantees are provided
Microservice Architecture - The anatomy of a Rumi microservice
Understand the structure of a Rumi microservice:
Runtime Architecture - The runtime components (AEP Engine, SMA, container, etc.)
Development Model - Development artifacts (ADM models, user code, configuration)
Configuration Model - How configuration is managed and applied
Operational Concepts
Microservice Operation - How microservices behave at runtime
Follow a microservice through its complete lifecycle:
Lifecycle - Complete microservice lifecycle with all phases and events
Initialization - How microservices start up and initialize
Cluster Join - How instances discover and join clusters
Message Processing - The message processing loop and transaction flow
Cluster Consensus - How distributed consensus is achieved
Cluster Failover - Handling primary failures and backup promotion
High Availability & Consistency
Consensus Models - State Replication vs Event Sourcing
Rumi provides two consensus models for achieving high availability:
Event Sourcing - Replicate inbound messages for deterministic state reconstruction
State Replication - Replicate state changes automatically
Understand the trade-offs between latency, complexity, and flexibility.
Transactions - ACID guarantees in distributed systems
Learn how Rumi provides transactional guarantees:
Atomic commits of state changes and outbound messages
Transaction isolation and consistency
Integration with consensus models
Savepoints and transaction control
Platform Services
Threading Model - How Rumi manages concurrency
Rumi's single-threaded business logic model eliminates race conditions while maintaining high throughput:
Thread architecture and responsibilities
Disruptor-based event processing
Thread affinitization for performance
NUMA-aware configuration
Discovery Model - How components find each other
The discovery service enables microservices to locate:
Other microservice instances for clustering
Containers for deployment
Message buses for connectivity
Discovery providers (Multicast, SMA, Local)
Operating Model - Administration, monitoring, and troubleshooting
Understand the operational aspects:
Statistics collection and heartbeats
Administrative commands and control
Analysis and troubleshooting tools
Performance monitoring
Architecture Principles
Rumi's architecture is guided by several key principles:
1. Event-Driven Processing
All business logic executes in response to events (messages, lifecycle events, timer events). This ensures deterministic, reproducible behavior across instances.
2. Single-Threaded Business Logic
Message handlers execute on a single thread, eliminating the need for locks, mutexes, or concurrent data structures in application code.
3. Transparent High Availability
Clustering, replication, and failover happen automatically without application code changes. The platform handles distributed consensus.
4. Message-Oriented Architecture
Communication between microservices happens exclusively through messages. This loose coupling enables independent deployment and scaling.
5. Strong Typing
All messages and state are strongly-typed POJOs generated from declarative models. This eliminates serialization errors and provides compile-time safety.
6. Configuration as Code
All runtime configuration is expressed in declarative XML (DDL) with support for templating, profiles, and overrides.
How These Concepts Fit Together
Here's how the concepts relate to building and running a Rumi microservice:
Development: Use the Development Model to understand what artifacts you create (ADM models, handlers, configuration)
Runtime: The Runtime Architecture shows how those artifacts are loaded and executed by the AEP Engine, SMA, and container
Communication: The Messaging Model explains how your microservice sends and receives messages via the SMA
Lifecycle: Microservice Operation describes what happens from startup through steady-state processing to shutdown
High Availability: Consensus Models and Transactions explain how consistency and fault tolerance are achieved
Performance: The Threading Model and Discovery Model describe how Rumi achieves ultra-low latency
Operations: The Operating Model covers monitoring, administration, and troubleshooting
Next Steps
After understanding the concepts in this section, proceed to:
Developing Applications - Put these concepts into practice by building microservices
Microservice Template - Start with template projects for Event Sourcing or State Replication
Reference - Look up specific annotations, events, and configuration elements
Additional Resources
For hands-on learning:
Start with Get Started to set up your development environment
Review Introduction for a high-level overview of Rumi
Explore the Microservice Template section for complete implementation examples
Last updated