Applies toOCI Queue, OCI Streaming (Kafka-compatible), OCI Notifications, OCI Events, Connector Hub, Oracle Integration (OIC) for application integration
Which job?
| Job | Service |
|---|---|
| Work items that one consumer must process reliably | Queue |
| High-volume ordered event stream, replay, Kafka clients | Streaming |
| Fan-out alerts/messages to email, SMS, HTTPS, Slack, PagerDuty, Functions | Notifications |
| React to OCI resource changes (instance terminated, object created, backup failed) | Events |
| Move data between OCI services (logs → Object Storage, stream → Functions) without code | Connector Hub |
| Business application integration (SaaS adapters, mapping, orchestration) | Oracle Integration |
Comparison
| Queue | Streaming | Notifications | Events | Connector Hub | |
|---|---|---|---|---|---|
| Model | Queue (pull, visibility timeout) | Partitioned log | Pub/sub push | Rule-based event routing | Source → (task) → target pipelines |
| Ordering | Not strict (check channels/FIFO options) | Per partition | No | No | Follows source |
| Replay | No | Within retention | No | No | Depends on source |
| Retry / DLQ | Max delivery attempts + dead letter queue | Consumer-managed offsets | Delivery retries per protocol | Delivered to action targets (Notifications, Functions, Streaming) | Retries; source position tracking |
| Typical consumers | Workers, Functions | Stream processors, Kafka apps, Data Flow | People, chat, paging, Functions | Automation | Archival, analytics, SIEM |
Common combinations
Object uploaded ─► Events rule ─► Functions ─► Queue ─► workers (reliable processing, DLQ)
Backup failed event ─► Events rule ─► Notifications topic ─► email + chat + paging
App events ─► Streaming ─► Connector Hub ─► Object Storage (archive) + Functions (enrichment)
Logs ─► Connector Hub ─► Streaming ─► external SIEM (Kafka consumer)
Placing a Queue between an event and a worker adds buffering, retries and controlled concurrency.
Design must-haves
| Service | Design |
|---|---|
| Queue | Visibility timeout > processing time, max delivery attempts, DLQ monitoring and redrive process |
| Streaming | Partition key for ordering, partitions for throughput, consumer group offsets, retention for replay |
| Notifications | Subscription confirmation, HTTPS endpoint reliability, separate topics by severity |
| Events | Precise rule conditions to avoid floods; action targets that can handle bursts |
| Connector Hub | Monitor connector health and lag; IAM policies for source/target |
Delivery is at-least-once in practice: make consumers idempotent.
Operational signals
- Queue: visible messages, oldest message age, DLQ size.
- Streaming: put/get throttling, consumer lag per group.
- Notifications: failed deliveries.
- Connector Hub: errors, latency/backlog.
Warning
Notifications isn't a durable work queue. If an HTTPS subscriber is down beyond the retry period, messages are lost. For work that must happen, put it in a Queue or Stream.
Checklist
- Job type identified per flow
- Ordering, replay and fan-out needs answered
- Retries, DLQs and idempotency designed
- IAM policies for connectors and rules
- Lag/backlog/failure alarms in place