sqs-mini – Eventdriven Pipeline
Backend-projekt som visar en eventdriven pipeline: ett Minimal API publicerar meddelanden till AWS SQS, en .NET Worker Service konsumerar dem med long polling och idempotent bearbetning, och misslyckanden routas till en DLQ. Infrastrukturen provisioneras i C# via Pulumi.
Teknikstack
C# · .NET · AWS SQS · Pulumi · Minimal API · Worker Service · SQLite
Problem / Kontext
Meddelandeköer, retries och idempotenta konsumenter är mönster jag stötte på gång på gång i backend-diskussioner men aldrig byggt själv. sqs-mini är min fungerande implementation av hela flödet: ett Minimal API publicerar till SQS, en Worker Service hämtar det, bearbetar det en gång (SQLite håller koll på sedda meddelande-ID:n), och allt som misslyckas tillräckligt många gånger hamnar i DLQ. Pulumi provisionerar AWS-uppsättningen i C#, samma språk som resten av projektet.
Lösning / Arkitektur
Projektet består av två .NET-applikationer: ett Minimal API (`SessionApi`) som fungerar som meddelandeproducer och en Worker Service (`BillingWorker`) som fungerar som konsument. Infrastrukturen – en SQS Standard Queue och dess DLQ – provisioneras med Pulumi i C#. Workern använder long polling för effektiv meddelandeemottagning, behandlar meddelanden idempotent med en SQLite-lagring för att spåra redan hanterade meddelande-ID:n, och låter SQS hantera retries och DLQ-routing för obehandlingsbara meddelanden. Runtimekonfiguration är miljöbaserad för att hålla kredentialer och kö-URL:er utanför källkoden.
Mål
- Demonstrera ett realistiskt producer → queue → consumer-flöde
- Provisionera AWS-infrastruktur deklarativt med Pulumi IaC i C#
- Implementera long polling i en .NET Worker Service
- Hantera idempotens med en SQLite-baserad meddelande-ID-lagring
- Visa retries och dead-letter queue-beteende tydligt
Utmaningar
- Designa ett idempotenslagring som är lättviktigt men tillförlitligt för demoändamålet
- Konfigurera Pulumi för att provisionera SQS-köer med korrekt DLQ-koppling och retry-policy
- Hantera miljöbaserad konfiguration rent utan att läcka hemligheter i källkoden
Viktiga tekniska beslut
- Pulumi i C# för IaC – håller hela stacken i ett språk som teamet känner till
- SQLite för idempotenslagring – noll infrastrukturkostnad för demo, enkel att byta mot Redis eller DynamoDB i produktion
- Worker Service-mönster – det idiomatiska .NET-sättet för långvariga bakgrundskonsumenter
- Minimal API för producer – lättviktigt och snabbt att sätta upp
Resultat / Effekt
- En fungerande eventdriven pipeline: API publicerar till SQS, Worker konsumerar, DLQ fångar fel
- Infrastruktur fullt reproducerbar med ett enda Pulumi-kommando
- Praktisk förståelse för distribuerade systemmönster: idempotens, retries, DLQ, at-least-once delivery
Vad jag skulle förbättra härnäst
- Ersätt SQLite-idempotenslagring med DynamoDB för en fullt molnbaserad lösning
- Lägg till strukturerad loggning och observability med CloudWatch
- Utöka till FIFO-kö för strikta ordningsgarantier