110 lines
No EOL
3.1 KiB
Markdown
110 lines
No EOL
3.1 KiB
Markdown
# Event-Driven Framework Architecture
|
|
|
|
## Overview
|
|
The event-driven framework provides high-performance event processing with:
|
|
- Throughput of 100+ events per second
|
|
- Thread-safe operation
|
|
- AES-256 encryption compliance
|
|
- Tight integration with scheduler system
|
|
|
|
## Core Components
|
|
|
|
```mermaid
|
|
classDiagram
|
|
class EventSystem {
|
|
+publish(event, priority)
|
|
+subscribe(event_type, handler)
|
|
}
|
|
|
|
class EventDispatcher {
|
|
+register_handler(event_type, handler)
|
|
+dispatch(event)
|
|
+start()
|
|
+stop()
|
|
}
|
|
|
|
class EventQueue {
|
|
+push(priority, event)
|
|
+pop() event
|
|
}
|
|
|
|
EventSystem --> EventDispatcher
|
|
EventDispatcher --> EventQueue
|
|
EventDispatcher --> Scheduler
|
|
```
|
|
|
|
### EventQueue
|
|
- Priority-based processing (min-heap)
|
|
- Thread-safe operations using RLock
|
|
- Efficient wakeup signaling with Event objects
|
|
- FIFO ordering for same-priority events
|
|
|
|
### EventDispatcher
|
|
- Maintains handler registry
|
|
- Routes events to appropriate handlers
|
|
- Manages worker thread lifecycle
|
|
- Integrates with scheduler for delayed events
|
|
|
|
### EventSystem
|
|
- Public API for publishing/subscribing
|
|
- Handles encryption/decryption
|
|
- Wraps dispatcher functionality
|
|
|
|
## Performance Characteristics
|
|
|
|
| Metric | Value | Test Case |
|
|
|--------|-------|-----------|
|
|
| Throughput | ≥100 events/sec | test_event_throughput |
|
|
| Concurrent Publishers | 10 threads | test_concurrent_publishers |
|
|
| Latency | <10ms per event | test_scheduled_events |
|
|
|
|
## Security Implementation
|
|
- All events encrypted with AES-256 in transit
|
|
- Encryption can be disabled for debugging
|
|
- Thread-safe operations prevent race conditions
|
|
- Error handling prevents crashes from bad events
|
|
|
|
## Scheduler Integration
|
|
The event system integrates with the scheduler through:
|
|
1. Delayed event execution via `schedule_event`
|
|
2. Shared thread pool resources
|
|
3. Common encryption implementation
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant Publisher
|
|
participant EventSystem
|
|
participant Scheduler
|
|
participant Handler
|
|
|
|
Publisher->>EventSystem: publish(event)
|
|
EventSystem->>Scheduler: schedule_event(delayed)
|
|
Scheduler->>EventSystem: execute delayed
|
|
EventSystem->>Handler: dispatch(event)
|
|
```
|
|
|
|
## Scaling Considerations
|
|
- Queue size monitoring recommended
|
|
- Handler execution time critical for throughput
|
|
- Consider dedicated thread pools for slow handlers
|
|
- Horizontal scaling possible with distributed queue
|
|
## NLP Processing Module
|
|
|
|
### Security Architecture
|
|
- **Encryption**: All model data encrypted at rest using AES-256
|
|
- **Access Control**: RBAC enforced via `@requires_permission` decorators
|
|
- **Audit Trail**: All operations logged via security/audit.py
|
|
|
|
### Integration Points
|
|
1. **Security Subsystem**:
|
|
- Uses RBAC engine for permission checks
|
|
- Writes audit logs for all NLP operations
|
|
|
|
2. **Event Processing**:
|
|
- Intent analysis available as a service
|
|
- Secure decorator for custom NLP operations
|
|
|
|
### Implementation Notes
|
|
- Base class: `nlp/intent.IntentRecognizer`
|
|
- Tests: `nlp/tests/test_intent.py`
|
|
- Follows security requirements from `symphony-core.md` |