8. Serverless and Event-Driven Deployment

Introduction and Context

Cloud deployment has progressively moved from manually managed servers toward increasingly abstract services. Virtual machines removed the need to purchase physical hardware, containers simplified application packaging, and managed platforms reduced the operational work associated with runtime environments. Serverless computing extends this progression by allowing developers to deploy application logic without directly managing servers, operating systems, or runtime capacity. The cloud provider provisions infrastructure, executes code when required, and commonly charges according to invocation, execution duration, requests, or other measured consumption.

Serverless does not mean that servers disappear. Servers remain essential, but their provisioning, patching, scaling, and much of their capacity management are delegated to the provider. This arrangement is particularly valuable for APIs, background jobs, data-processing tasks, notifications, automation, and applications with irregular or unpredictable workloads.

Event-driven architecture complements serverless deployment. Instead of requiring every component to communicate synchronously through direct calls, a system can respond to events such as an order being placed, a file being uploaded, a payment being authorised, or a database record being changed. Producers publish events, while consumers react to them independently. Queues, topics, event buses, and workflow services provide the communication and coordination mechanisms required for such systems.

For postgraduate developers, the important question is not whether serverless is fashionable, but when its operating model is appropriate. A sound design must consider latency, execution limits, reliability, security, observability, cost, data consistency, team capability, and the consequences of dependence on a particular cloud provider.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Explain the operating model and terminology of serverless and event-driven systems.

2. Compare functions-as-a-service, managed application platforms, containers, and virtual machines.

3. Design APIs using synchronous and asynchronous communication appropriately.

4. Select and apply queues, topics, event buses, and workflow orchestration.

5. Evaluate cold starts, concurrency, execution limits, retries, ordering, and duplicate delivery.

6. Design observability, security, resilience, and governance controls for serverless systems.

7. Assess cost, operational suitability, portability, and vendor lock-in.

8. Apply serverless principles to a realistic cloud deployment scenario.

The Serverless Operating Model

A serverless service typically has four characteristics. First, infrastructure management is abstracted from the application team. Second, capacity can scale automatically in response to demand. Third, billing is associated with actual consumption rather than permanently allocated servers. Fourth, application components are often designed as small, independently deployable units.

Functions-as-a-Service (FaaS) is the most recognisable serverless model. A function contains code that is invoked by an HTTP request, message, schedule, file event, database change, or another cloud event. Examples include AWS Lambda, Google Cloud Functions, and Azure Functions. A function normally has a defined entry point, a runtime such as Python, JavaScript, Java, Go, or .NET, configured memory and timeout values, and permissions to access other resources.

A function invocation may be synchronous or asynchronous. In a synchronous invocation, the caller waits for a response. This is appropriate for an API request where the user needs an immediate result. In an asynchronous invocation, the provider accepts the event and attempts delivery to the function without requiring the original caller to remain connected. This is useful for image processing, notifications, and background tasks.

Managed application platforms occupy a related but broader position. Services such as AWS App Runner, Google App Engine, and Azure App Service allow teams to deploy an application or container while the platform manages much of the infrastructure and scaling. These platforms are often better suited to long-running web applications, applications requiring stable processes, or workloads that do not fit function limits. Thus, serverless should be understood as a spectrum of managed execution models rather than a single product category.

Important Concepts and Terminology

An event is a recorded occurrence that may trigger processing. An event should normally contain an event type, time, source, subject or resource identifier, and relevant data. An event producer creates or publishes an event, while an event consumer processes it.

A queue stores messages until a consumer is ready to process them. Queues decouple producers and consumers, absorb temporary traffic surges, and support workload smoothing. A topic distributes messages to multiple subscribers, often using publish-subscribe semantics. An event bus provides a central routing mechanism for events from multiple sources to multiple targets according to rules.

A dead-letter queue (DLQ) stores messages that cannot be successfully processed after a configured number of attempts. It prevents problematic messages from being retried indefinitely and enables later investigation or replay. Visibility timeout is the period during which a message being processed is hidden from other consumers. If processing does not complete within that period, the message may become visible again.

Idempotency means that performing an operation more than once produces the same intended business result as performing it once. It is essential because distributed systems commonly deliver messages more than once. An idempotent payment-status update, for example, can safely ignore a repeated event with the same transaction identifier.

Concurrency refers to the number of function instances executing simultaneously. Reserved concurrency can protect a downstream database from overload, whereas excessive restriction can create a backlog. Provisioned or pre-warmed capacity reduces cold-start latency by keeping execution environments ready, although it increases cost.

A cold start occurs when the provider creates a new execution environment before running a function. It may involve downloading code, starting the runtime, loading dependencies, and establishing connections. A warm invocation reuses an existing environment and is generally faster. Cold starts vary according to runtime, package size, initialisation work, memory allocation, and provider configuration.

Orchestration coordinates multiple steps, including branching, waiting, retrying, compensation, and failure handling. A workflow service such as AWS Step Functions, Google Workflows, or Azure Durable Functions can express these relationships explicitly. Choreography, in contrast, allows services to react to events independently without a central coordinator. Orchestration improves visibility and control; choreography can reduce central dependency but may become difficult to understand when many interactions accumulate.

From Request-Response to Event-Driven Design

Traditional web applications commonly follow a request-response model. A client sends a request to an API, the application performs processing, and a response is returned. This model is simple and appropriate when the caller requires an immediate answer. However, it creates temporal and operational coupling: the client, API, database, and downstream services must be available during the same interaction.

Event-driven design separates the creation of an event from its processing. For example, an order service can publish `OrderPlaced` after recording an order. Inventory, billing, fulfilment, analytics, and notification services can subscribe independently. If the analytics service is temporarily unavailable, the order service need not fail, provided the event has been durably accepted.

This separation improves resilience and scalability, but it changes the programming model. There may be delayed results, eventual consistency, duplicate events, and more complex troubleshooting. A developer must distinguish between commands and events. A command asks a specific component to perform an action; an event states that something has happened. Commands usually have one intended handler, while events may have many consumers.

A useful design process begins with business events rather than cloud products. Identify important state changes, determine which components need to know about them, define event schemas, and decide which operations require immediate confirmation. Use synchronous APIs for validation and immediate decisions; use asynchronous events for work that can be completed later or independently.

Communication Patterns and Integration Services

Queues

A queue is suitable when work should normally be processed by one consumer or one competing consumer in a group. It provides buffering between uneven production and consumption rates. Workers retrieve messages, perform processing, and acknowledge successful completion. If processing fails, the message can be retried. A queue should be configured with an appropriate visibility timeout, retention period, maximum delivery attempts, and dead-letter destination.

Queue-based systems require careful treatment of message acknowledgement. A consumer should acknowledge a message only after the associated work is durably complete. Acknowledging too early risks data loss; acknowledging too late can cause duplicate processing. Long-running work may require extending the visibility timeout or dividing the task into smaller units.

Topics and Publish-Subscribe

A topic allows one event to be delivered to multiple subscriptions. Each subscriber receives its own delivery and can process it independently. This pattern is valuable when a single business event has several consequences. Subscription filters can prevent consumers from receiving irrelevant events, reducing cost and processing overhead.

Topics often support fan-out, but they do not automatically solve schema governance. Producers and consumers need an agreed event contract, versioning strategy, and compatibility policy. Adding optional fields is generally safer than changing the meaning of existing fields. Breaking changes should be represented through a new version or event type.

Event Buses

An event bus routes events according to source, type, subject, account, environment, or data attributes. It is useful in organisations where many applications publish events and independently maintained services subscribe to them. Event buses support loose coupling and central routing rules, but governance is necessary to prevent an uncontrolled collection of undocumented events.

A well-managed event bus defines ownership, naming conventions, security boundaries, retention expectations, and monitoring responsibilities. Cross-account or cross-project event delivery should be explicitly authorised and logged.

Workflows

Workflows are appropriate when a business process contains multiple dependent steps. Consider an account-opening process: validate identity, check risk, create an account, issue credentials, and send a notification. A workflow can define sequential execution, parallel branches, timeouts, retries, and compensation if a later step fails.

A workflow is not merely a collection of function calls. It is a durable representation of process state. The designer must decide which steps are retryable, which failures are permanent, and how partial completion is reversed or reconciled. Compensation is often preferable to attempting a technical rollback across independent services. For example, if a shipment has been created but payment later fails, the system may issue a cancellation rather than trying to undo every prior action atomically.

Designing Serverless APIs

A serverless API commonly consists of an API gateway, an authentication mechanism, one or more functions, and managed data services. The gateway can provide routing, TLS termination, request validation, throttling, access control, logging, and version management. Functions should focus on business logic rather than repeating gateway responsibilities.

API design must account for payload limits, timeout limits, authentication latency, error mapping, and downstream capacity. A function should validate input at the boundary, use structured errors, and avoid exposing internal implementation details. Long-running operations should usually return an accepted status and a job identifier rather than keeping an HTTP connection open. The client can poll a status endpoint or receive a notification when processing completes.

Statelessness is a strong default. A function instance may be destroyed or reused unpredictably, so durable state should be stored in a database, object store, cache, or queue. Temporary local storage can be useful for intermediate files but should not be treated as permanent. Connection pooling requires care: reusing connections in warm environments can improve performance, but excessive concurrent connections can exhaust a database. Managed proxies, connection limits, and concurrency controls may be required.

Reliability, Limits, and Failure Behaviour

Serverless systems are constrained by provider limits. These may include maximum execution duration, memory, deployment package size, request payload size, concurrency quotas, event retention, message size, and rate limits. Limits differ across AWS, GCP, and Azure and may vary by region or service tier. They must be checked during design rather than discovered in production.

Retries are valuable for transient failures but dangerous when applied indiscriminately. A retry policy should specify maximum attempts, delay, exponential backoff, and jitter. Without jitter, many clients may retry simultaneously and create a retry storm. Non-transient errors, such as invalid input, should normally be routed to a failure path rather than retried repeatedly.

At-least-once delivery is common in cloud messaging. It provides strong delivery assurance at the cost of possible duplicates. Exactly-once business outcomes are therefore usually achieved through idempotency, deduplication keys, conditional writes, and transactional records rather than by assuming that transport delivers each message once.

Ordering is another design consideration. Some services offer ordering only within a partition, message group, or key. Global ordering can limit scalability. If events concerning one customer or account must be ordered, use a stable partition key and design consumers to detect stale or out-of-sequence events.

Observability and Operational Control

Serverless applications require observability across distributed boundaries. Logs should be structured and include correlation identifiers, event identifiers, function version, tenant or request context where appropriate, and outcome. Sensitive data must not be written casually to logs.

Metrics should cover invocation count, duration, error rate, throttling, concurrency, queue depth, age of the oldest message, retry count, dead-letter volume, and workflow failures. Technical metrics should be related to service-level objectives. For example, a queue-depth alarm is more meaningful when linked to a maximum acceptable processing delay.

Distributed tracing helps connect an API request to function invocations, queue messages, database operations, and downstream services. Trace context should be propagated through asynchronous messages where supported. Because asynchronous systems may complete long after the initiating request, operational dashboards should display both the original correlation identifier and the current processing state.

Effective alerting distinguishes symptoms from causes. A high function error rate may result from a database outage, invalid events, expired credentials, or a deployment defect. Runbooks should explain diagnosis, rollback, replay, and DLQ recovery procedures. Observability is therefore not only a monitoring concern; it is part of system design.

Security, Governance, and Professional Responsibility

Serverless security follows the principle of least privilege. Each function should receive only the permissions required for its task. Separate execution roles, deployment roles, and administrative roles reduce the impact of compromise. Secrets should be stored in a managed secret service rather than embedded in source code or environment files committed to a repository.

API endpoints require authentication, authorisation, input validation, rate limiting, and protection against abuse. Event consumers must verify that events originate from trusted sources and that payloads have not been tampered with. Encryption should protect data in transit and at rest, while data classification determines retention and access requirements.

Governance becomes more difficult when teams can create functions and event routes rapidly. Organisations should establish naming standards, tagging, ownership metadata, environment separation, approved runtimes, dependency scanning, infrastructure-as-code requirements, and logging policies. Compliance requirements may restrict data location, retention, processing purpose, or cross-border transfer.

Ethically, asynchronous design must not obscure responsibility. A customer should not be denied meaningful information merely because a decision is processed by a chain of functions. Systems involving financial eligibility, employment, healthcare, or identity require explainability, auditability, human review where appropriate, and careful treatment of personal data.

Cost, Performance, and Vendor Lock-In

Serverless pricing can be attractive for intermittent workloads because idle capacity is not continuously provisioned. However, cost depends on invocation volume, execution duration, memory, data transfer, API gateway requests, logs, queue operations, workflow transitions, and managed database usage. Excessive function decomposition can create many network calls and observability charges.

Performance optimisation should begin with measurement. Reduce package size, defer unnecessary initialisation, choose suitable memory, reuse safe connections, and avoid loading large dependencies on every invocation. Provisioned capacity may be justified for latency-sensitive APIs. For asynchronous workloads, throughput and processing delay may matter more than single-request latency.

Vendor lock-in has several dimensions: proprietary function triggers, event schemas, workflow languages, identity systems, databases, monitoring tools, and operational knowledge. Portability does not require avoiding all provider services. It requires making the level of dependence deliberate. Teams can reduce unnecessary lock-in through containerised functions where suitable, portable event schemas, domain-level interfaces, infrastructure-as-code abstractions, contract tests, exportable data, and documented migration assumptions. Excessive abstraction, however, can remove useful provider capabilities and increase development cost. The appropriate objective is informed dependence rather than absolute provider neutrality.

Applied Case: An Asynchronous Retail Order Platform

Background

This illustrative case concerns Northstar Retail, an online retailer whose monolithic application handles browsing, ordering, payment initiation, inventory reservation, fulfilment, and email notifications. During promotional campaigns, order traffic becomes highly variable. The application has experienced timeouts because slow email and fulfilment operations remain inside the customer-facing request.

Situation and Problem

The organisation wants to improve peak resilience without operating a large permanent server fleet. It also needs reliable order processing, traceability, and the ability to add new consumers such as analytics without changing the ordering component.

Analysis

The customer requires immediate confirmation that the order request was accepted, but does not require fulfilment and notification to finish before receiving a response. Payment authorisation and inventory reservation require careful business rules. Email delivery and analytics are naturally asynchronous. The design must handle duplicate events because retries are expected, and it must prevent uncontrolled concurrency from overwhelming the inventory database.

Approach and Solution

An API gateway exposes the order endpoint. An order function validates the request, writes an order with a unique idempotency key, and publishes an `OrderPlaced` event only after the order record is durably stored. The API returns an order identifier and an accepted status.

A workflow coordinates payment authorisation and inventory reservation. If payment fails, the order is marked as rejected. If inventory reservation fails after payment succeeds, a compensation step requests payment reversal. The workflow records state transitions so that support staff can determine where processing stopped.

The `OrderPlaced` event is delivered through a topic. A notification subscription sends confirmation email, while an analytics subscription records a business event in a reporting store. A fulfilment queue receives work for warehouse processing. The fulfilment consumer uses the order identifier as an idempotency key and acknowledges the message only after the fulfilment request is durably recorded.

Concurrency limits are applied to the inventory consumer. Failed messages are retried with exponential backoff and then moved to a dead-letter queue. Structured logs and trace identifiers connect the original API request, workflow execution, event delivery, and fulfilment activity. Dashboards monitor order acceptance latency, workflow failure rate, queue age, duplicate processing, and DLQ volume.

Outcome

The customer-facing API is no longer blocked by email or warehouse operations. Traffic bursts are absorbed by queues, and independent consumers can be scaled according to their workload. The architecture introduces eventual consistency and requires operational practices for replaying events and resolving failed orders, but these costs are visible and manageable.

Learning Points

The case illustrates that serverless architecture is not simply a decision to replace a server with a function. It requires separating immediate decisions from deferred work, defining durable state transitions, designing for duplicate delivery, controlling downstream pressure, and providing operational evidence across service boundaries.

Common Mistakes and Design Trade-offs

A frequent mistake is to create a function for every small method without considering network latency, deployment complexity, and observability. Function boundaries should reflect meaningful ownership and scaling needs, not merely source-code size. Another mistake is placing long-running or highly stateful workloads in a function environment that imposes strict time and storage limits.

Teams also commonly assume that retries guarantee reliability. Retries without idempotency can create duplicate charges, repeated emails, or inconsistent records. Similarly, a DLQ is not a complete failure strategy unless someone monitors it, understands the cause, and has a safe replay procedure.

Eventual consistency may be unacceptable for certain operations. A balance update, access-control decision, or inventory reservation may require stronger coordination than an analytics update. The correct design depends on business impact, not on a general preference for asynchronous systems.

Finally, serverless can increase operational complexity even while reducing infrastructure administration. The organisation must invest in cloud governance, testing, tracing, incident response, cost management, and platform expertise. Architectural simplicity should be evaluated from the perspective of the complete system and its operating team.

Current Developments and Emerging Directions

Serverless platforms increasingly support container-based functions, longer-running workloads, GPU or specialised compute options, and event integration across multiple cloud services. Managed workflow and event-routing products are becoming more expressive, while platform engineering teams are creating internal templates that standardise security, observability, deployment, and cost controls.

The boundary between serverless functions, managed containers, and edge computing is also becoming less distinct. Edge execution can reduce latency by processing requests nearer to users, but it may impose stricter runtime, data, and debugging limitations. Event-driven data processing is expanding through streaming platforms, change-data-capture systems, and real-time analytics services.

Artificial intelligence workloads can use serverless components for request validation, orchestration, retrieval, notification, and asynchronous job management. However, model execution may require specialised infrastructure, predictable throughput, or long-running sessions. AI integration therefore reinforces the need to choose execution models according to workload characteristics rather than adopting serverless uniformly.

Best-Practice Design Checklist

A professional serverless deployment should:

• define clear synchronous and asynchronous boundaries;
• document event schemas, ownership, versioning, and retention;
• make consumers idempotent and configure deliberate retry policies;
• use dead-letter handling with monitoring and replay procedures;
• set concurrency, timeout, memory, and rate limits based on evidence;
• protect downstream systems from uncontrolled fan-out;
• apply least-privilege identity and managed secret storage;
• use infrastructure as code and automated contract testing;
• instrument logs, metrics, traces, correlation IDs, and business outcomes;
• model cost, provider limits, and portability before production;
• test failure, duplicate delivery, timeout, throttling, and recovery scenarios.

Chapter Summary

Serverless deployment abstracts infrastructure management while providing elastic, consumption-based execution. Functions-as-a-Service is useful for APIs, event handlers, scheduled work, and short-lived processing, while managed application platforms and containers remain suitable for longer-running or specialised workloads. Event-driven architecture uses events, queues, topics, buses, and workflows to decouple producers and consumers and to absorb variable demand.

Effective designs distinguish immediate request-response interactions from deferred asynchronous processing. They account for cold starts, concurrency, execution limits, retries, ordering, duplicate delivery, and eventual consistency. Idempotency, dead-letter queues, durable workflow state, and controlled concurrency are central reliability techniques. Observability must connect distributed operations through structured logs, metrics, traces, and business-level monitoring.

Security requires least privilege, protected secrets, validated inputs, authenticated event sources, encryption, and governance. Serverless may reduce infrastructure effort and suit irregular workloads, but cost, operational complexity, provider limits, and vendor lock-in must be evaluated. The most appropriate architecture is determined by business requirements, workload behaviour, risk, and organisational capability.

Key Terms

Serverless: A cloud execution model in which infrastructure provisioning and capacity management are largely delegated to the provider.

Functions-as-a-Service: A model that runs discrete application functions in response to requests, events, or schedules.

Function invocation: A single execution request delivered to a serverless function.

Event: A recorded occurrence that can be published, routed, and processed by one or more consumers.

Event producer: A component that creates or publishes an event.

Event consumer: A component that receives and processes an event.

Queue: A durable or semi-durable store that buffers messages for later processing.

Topic: A publish-subscribe channel that distributes messages to multiple subscribers.

Event bus: A routing service that directs events from sources to targets according to rules.

Workflow orchestration: Coordinated management of multiple processing steps, states, retries, and branches.

Cold start: Initial latency caused by creating and initialising a new function execution environment.

Warm invocation: Execution using an already initialised function environment.

Concurrency: The number of function executions occurring at the same time.

Idempotency: The property that repeated processing produces the same intended business result as one processing attempt.

Dead-letter queue: A destination for messages that fail processing after configured retry attempts.

Visibility timeout: The period during which a retrieved queue message is hidden from other consumers.

Eventual consistency: A condition in which distributed replicas or components become consistent after a delay.

Choreography: Event-driven coordination in which services react independently without a central workflow controller.

Vendor lock-in: Dependence on provider-specific technologies, interfaces, data formats, or operational practices.

Distributed tracing: Tracking a request or event across multiple services and execution components.

Review Questions

Short Answer Questions

1. What distinguishes a serverless function from a virtual machine?

2. Define cold start and identify two factors that can influence it.

3. Why is idempotency important in event-driven systems?

4. What is the purpose of a dead-letter queue?

5. Differentiate between a queue and a topic.

Long Answer Questions

1. Explain how an event-driven architecture changes the relationship between producers and consumers. Discuss its benefits and complications.

2. Describe the design of a reliable serverless API, including validation, state management, authentication, error handling, and observability.

3. Analyse the role of retries, backoff, idempotency, and dead-letter queues in reliable asynchronous processing.

4. Compare orchestration and choreography and explain the situations in which each may be appropriate.

5. Evaluate the relationship between serverless deployment, cost, performance, and vendor lock-in.

Analytical / Application Questions

1. An image-processing function receives large traffic spikes and frequently overloads a downstream database. Propose a revised architecture and justify your choices of queues, concurrency controls, retries, and monitoring.

2. A payment service sometimes processes the same payment event twice after a timeout. Design an idempotency strategy that prevents duplicate business outcomes while preserving reliable event delivery.

3. A university plans to deploy a student application using serverless functions, a topic, and a workflow. Identify two operations that should remain synchronous, two that should be asynchronous, and the governance controls required for personal data and auditability.

22. Multiple Choice Questions with Answers

Question 1

Which situation is most suitable for asynchronous serverless processing?

A. Returning an immediate password validation result

B. Processing an uploaded video after the upload is accepted

C. Checking whether an API token is structurally valid

D. Returning a product price required to complete checkout

Correct Answer: B. Processing an uploaded video after the upload is accepted

Question 2

What is the primary purpose of a queue in an event-driven system?

A. To permanently replace a database

B. To enforce global ordering across all events

C. To buffer work and decouple producers from consumers

D. To eliminate the need for authentication

Correct Answer: C. To buffer work and decouple producers from consumers

Question 3

A consumer receives the same order event twice. Which design property most directly prevents two orders from being created?

A. Idempotency based on a unique order or event identifier

B. Increasing the function timeout

C. Adding more event consumers

D. Removing retries from the queue

Correct Answer: A. Idempotency based on a unique order or event identifier

Question 4

What is a likely consequence of setting a queue visibility timeout shorter than the processing time?

A. The message is permanently deleted before processing

B. The message may become visible and be processed by another consumer

C. The queue automatically guarantees exactly-once delivery

D. The function receives unlimited execution time

Correct Answer: B. The message may become visible and be processed by another consumer

Question 5

Which control is most appropriate for protecting a database from excessive serverless concurrency?

A. Removing all timeout settings

B. Increasing the event payload size

C. Applying reserved concurrency or equivalent rate control

D. Disabling structured logging

Correct Answer: C. Applying reserved concurrency or equivalent rate control

Question 6

What is the main role of a workflow service in a serverless architecture?

A. To store every application file permanently

B. To coordinate steps, branching, retries, waiting, and compensation

C. To provide physical network cabling

D. To ensure that every event is processed globally in order

Correct Answer: B. To coordinate steps, branching, retries, waiting, and compensation

Question 7

Which statement best describes a cold start?

A. A failed database transaction caused by low storage

B. The latency of creating and initialising a new function environment

C. The delay caused only by a client using an old browser

D. A permanent shutdown of a serverless application

Correct Answer: B. The latency of creating and initialising a new function environment

Question 8

Which observability measure is most useful for detecting a growing asynchronous backlog?

A. Queue depth and age of the oldest message

B. The number of source-code comments

C. The colour of the deployment dashboard

D. The number of API documentation pages

Correct Answer: A. Queue depth and age of the oldest message

Question 9

Which approach best reduces unnecessary vendor lock-in while retaining useful managed services?

A. Avoiding all cloud services and operating physical servers

B. Using documented event contracts, portable interfaces, and explicit migration assumptions

C. Copying provider-specific credentials into every function

D. Using undocumented proprietary data formats everywhere

Correct Answer: B. Using documented event contracts, portable interfaces, and explicit migration assumptions

Question 10

A notification service is temporarily unavailable after an order event is published. Which design best preserves the event for later processing?

A. Use a topic subscription with durable delivery and retry or dead-letter handling

B. Discard the event immediately after publication

C. Make the customer resend the order

D. Disable all other event consumers

Correct Answer: A. Use a topic subscription with durable delivery and retry or dead-letter handling