A managed service provider runs a small Python service that receives Meraki alert webhooks for the customer networks it monitors. Every delivery must be answered within a second, only alerts naming a network on the watch list may be recorded, and a malformed body must be logged instead of crashing the process. How should the receiver validate each delivery to meet all three requirements?

The correct approach handles the webhook’s three distinct obligations: safe parsing prevents malformed input from crashing the process, logging preserves visibility into bad deliveries, and filtering ensures only alerts naming watched networks are recorded. Queuing watched alerts lets the receiver acknowledge promptly without waiting for downstream storage, supporting the one-second response requirement. Synchronous persistence is a standard design when durable storage is needed before acknowledgment, but it fails the response-time requirement here: database latency, retries, or contention can delay the response beyond a second, even if the write is usually fast. Recording every valid alert is also a common ingestion pattern, especially when filtering is deferred to a later pipeline stage; it fails this scenario’s requirement that only watched-network alerts be recorded. Silently discarding malformed bodies can protect a service from crashing, but it fails the explicit logging requirement and leaves operators without a record to diagnose invalid deliveries. Exam caveat: returning HTTP 200 quickly does not itself guarantee that queued work will be persisted, so the queue and its failure handling must be reliable. Practical check: test valid watched and unwatched payloads plus malformed JSON, measure acknowledgment latency under storage load, and verify that only watched alerts are stored and malformed deliveries appear in logs.