Messaging - Queues
1. System Context
Developers use Nitric to declare message queues within their application.
- App code uses the Queue resource from the Nitric SDK.
- Developers configure queues and implement application logic to send and receive messages.
Operations use default or overridden Terraform modules to provision the necessary resources for their target cloud.
Example AWS Provider
- AWS SQS serves as the message queuing service.
- AWS IAM provides roles and policies for secure access to SQS queues.
Example GCP Provider
- Google Pub/Sub Topic serves as the message queuing service.
- Google Pub/Sub Subscription emulates a queue by creating a pull subscription for the topic.
2. Sequence
3. Component
Queue Module
- Ensures the deployment of a scalable, provider-agnostic message queue with a consistent naming convention for seamless integration.
- Configures metadata or tags for resource identification, governance, and management.
- Implements secure access by dynamically assigning permissions to applications or services, enforcing the principle of least privilege.
- Supports configurable event-driven workflows, enabling the integration of producer-consumer patterns and worker pipelines.
- Provides dynamic configurations to handle varying workloads and queue-specific parameters such as message retention, delivery delay, and dead-letter queues.
- Abstracts the underlying queuing infrastructure, allowing developers and operations teams to focus on messaging logic rather than provider-specific APIs.
4. Code
Developers write application code that uses the Queue resource from the SDK, configures the secret, and implements the application logic to access and manage secrets.
SDK Reference by language -
Operations will use or extend the Nitric Terraform reference modules:
Last updated on Jan 24, 2025