sqs-mini – Eventdriven Pipeline
Backend-projekt som demonstrerar en eventdriven pipeline: ett Minimal API publicerar meddelanden till en AWS SQS-kö; en .NET Worker Service konsumerar dem med long polling, behandlar dem idempotent och routar fel 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-arkitekturdiskussioner men aldrig byggt från grunden. sqs-mini är min fungerande implementation av hela flödet: ett Minimal API publicerar ett meddelande till SQS, en Worker Service hämtar det, behandlar det en gång (SQLite håller koll på redan sedda meddelande-ID:n) och allt som misslyckas tillräckligt många gånger hamnar i DLQ:n. Pulumi provisionerar hela 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 end-to-end eventdriven pipeline: API publicerar → SQS levererar → Worker konsumerar → DLQ fångar fel
- Infrastruktur fullt reproducerbar med ett enda Pulumi-kommando
- Demonstrerad 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