Forsoning i skala er forskellen mellem at stole på dine finansielle optegnelser og tilbringe nætter på at jage uoverensstemmelser på tværs af flere parter. hos Lead Bank bygger vi infrastrukturen, der indsamler, behandler og forsoner data for kort- og indskudsprogrammer for at understøtte korrekthed, revisionsevne og overholdelsesforpligtelser. Forlig kontrollerer konsistens på tværs af bankkernen, kortnetværksfiler, udstedende processorrapporter og fintech-programdata. Fordi det spænder over flere parter, er arbejdsprocessen iboende multi-benet, og en enkelt mismatch kan udløse omkostningskrævende undersøgelser og øge compliance-risikoen. Dette indlæg går gennem den AWS-serverløse arkitektur, vi byggede til multi-party-forlig, de to produktionsflaskehalse, vi mødte først (filbearbejdningsgrænser og Amazon DynamoDB skrive hotspots), og de mønstre, vi brugte til at afbøde dem. I. Kontekst og tekniske begrænsninger for forsoning på skala I Banking-as-a-Service (BaaS) kortprogrammer opererer fintechs typisk gennem en Bank Identification Number (BIN) sponsor, en FDIC-forsikret udstedende bank, der har kortnetværkslicensen og er ansvarlig for afvikling og programovervågning. Et kortkøb begynder med en autoriseringsanmodning, som typisk føres i en ISO 8583-meddelelse, en fælles standard for korttransaktionsmeddelelser i realtid, der udveksles mellem erhververe og udstedere via kortnetværk. Den faktiske afvikling sker den næste dag, hvor netværket distribuerer netværksfiler til alle deltagere. Denne adskillelse mellem realtidsautorisering og batchafvikling er en primær grund til, at forsoning er fildrevet og operationelt kritisk. Forlig er den kontrol, der kontrollerer konsistens på tværs af interne poster og eksterne kilder til sandhed, herunder bankkernen, kortnetværket eller processorfiler og fintech-programdata.Da disse systemer adskiller sig i identifikatorer, timing og justeringssemantik, er forlig i sig selv multi-party og multi-step. I dette indlæg er enheden den endelige forbruger af fintech-programmet. En konto er et objekt, der indeholder en masse metadata om enhedernes forhold til fintech-programmet. Balance er et objekt, der har en værdi udtrykt i forskellige valutaer. En transaktion er et objekt, der beskriver en finansiel begivenhed, såsom et køb, betaling eller refusion, der ændrer værdien af en given saldo. Et kort er et af de instrumenter, der kan bruges til at udføre en transaktion og ændre saldoen. I praksis er forsoning opdelt i fire tilbagevendende arbejdsprocesser, som hver har forskellige tekniske begrænsninger: 
 
 
 
 
 Tjek de transaktioner, der udgør saldoen. Bevis for, at summen af kundeniveau saldi svarer til bankens kerne omnibus For-Benefit-Of (FBO) saldo. Match postede kortaktivitet til netværk eller processor afvikling filer på trods af volumen, format variabilitet, og mismatchede identifikatorer eller timing på tværs af parter. Valider identitets-, kortstatus- og kontoautoriseringsreferencedata, der kan ugyldiggøre en finansiel matchning, hvis den er ustabil eller inkonsekvent. Selvom mange arbejdsprocesser kører gennem applikationsprogrammeringsgrænsefladen (API), domineres forsoning stadig af end-of-day-filer, fordi de giver et auditerbart snapshot og understøtter deterministisk genbehandling. 
 
 
 
 
 Imperfekt fillevering og replays: filer ankommer sent, ude af orden, duplikeret eller rettet, så rørledningen skal være idempotent og sikkert at genstarte. Identifikatorer linjer ikke ordentligt: Den samme transaktion kan bære forskellige ID'er på tværs af parter, så matchning kræver ofte sammensatte nøgler og korrelationslogik. Justerings-tunge afviklingssemantik: refusioner, tvister, gebyrer og korrektioner ændrer matchende regler over tid og øger skriveforstærkning. To produktionsflasker dukker op tidligt: langvarig filbehandling kan overskride kortvarige beregningsgrænser, og højt skrivevolumen kan skabe ujævne adgangsmønstre og varme partitioner i forligsdatalageret. I dette indlæg fokuserer vi på de tekniske udfordringer ved finansiel forsoning, især balancekontrol og netværksafvikling matchning, og hvordan vi designet en AWS serverless pipeline omkring disse begrænsninger. Den serverløse arkitektur: Afkobling og orkestrering Med disse begrænsninger i tankerne forpligtede vi os til en serverfri-første arkitektur for at minimere driftsoverhead, maksimere tilgængelighed og understøtte automatisk skalering. Denne tilgang tillod vores lille team at iterere hurtigt og fokusere vores ingeniørarbejde på kompleks finansiel forretningslogik i stedet for infrastruktur vedligeholdelse og patching, hvilket reducerer vores udviklere og infrastruktur omkostningsprofil betydeligt. og For at holde artiklen enkel og fokuseret, vil vi kun fokusere på finansielle filer. Amazon Simple Storage Service (Amazon S3), Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS), Amazon DynamoDB, AWS Lambda, Amazon Elastic Container Service (Amazon ECS), AWS Step Functions A. Indtagelse og begivenhedsrouting (Amazon S3 og Amazon EventBridge) Processen begynder, når en af filerne (Transaktion, Balance eller Netværksafvikling) falder i en safe file transfer protocol (SFTP) mappe, der synkroniseres med S3 buckets. I vores design, vi routerede S3 objekt-skabte begivenheder gennem EventBridge i stedet for at bruge direkte S3 meddelelser. Dette gjorde indtagelse vej lettere at udvikle, fordi producenter og forbrugere forblev løst parret. Det gav os også et konsekvent sted at anvende filtrering og routing regler på tværs af flere begivenhedskilder. B. Bæredygtig forarbejdningskæde (Amazon SQS) I vores design målretter EventBridge-reglen en SQS-standardregning for at give holdbar buffering og afkoble indtagelse fra forarbejdning. 
 
 
 
 Hvis tre massive filer ankommer samtidigt, absorberer køen belastningen, hvilket hjælper med at sikre, at vores downstream computing-tjenester trækker beskeder med en stabil, bæredygtig hastighed i stedet for at blive overvældet. Holdbarhed: Meddelelserne forbliver i SQS, indtil de behandles med succes, hvilket garanterer mindst en levering. Dead Letter Queue (DLQ): Hver SQS-reje er konfigureret med en DLQ. Hvis en behandling Lambda fejler gentagne gange (f.eks. overstiger det maksimale retry-tælling på 5), flyttes meddelelsen til DLQ til manuel inspektion, så ingen transaktion er tavs tabt. C. Compute Layer (AWS Lambda og Amazon ECS) Vores computinginfrastruktur er strategisk opdelt for at optimere for både omkostninger og varighed: 
 
 
 AWS Lambda: Håndterer lette, sprængfyldte og orkestreringsarbejde, f.eks. analyse af meddelelser og udløsning af Step Function's parallelle kort. Lambda tilbyder ekstremt hurtige koldstart og lave omkostninger til efemere opgaver, der garanteres at blive afsluttet inden for 15 minutter. AWS ECS Fargate: Reserveret til forligsjob, der kræver høj hukommelse eller overstiger den 15-minutters Lambda timeout (en fælles flaskehalse, som beskrevet i afsnit III). D. Arbejdsprocesorkestrering (AWS Step Functions) Forlig er en langvarig, ofte flerdages arbejdsproces, så AWS Step Functions er en god løsning til serverløs orkestrering for at koordinere de enkelte beregningstrin. Vi valgte Step Functions specifikt, fordi det giver den holdbarhed og fejltolerance, der ikke kan forhandles for finansiel overensstemmelse, uden at vi behøver at skrive kompleks retry og statshåndteringskode. Årsagerne til dette valg er rodfæstet i arkitektonisk nødvendighed: 
 
 
 
 Styret tilstand og holdbarhed: Forlig involverer snesevis af sekventielle og parallelle trin (opdeling, normalisering, matchning, aggregering). Trinfunktioner styrer iboende tilstanden mellem trin, når en downstream-tjeneste fejler (f.eks. en Lambda-fejl). Massiv parallelisme via Map State: Afhængigt af vores brugstilfælde kørte vi visse opgaver parallelt ved hjælp af Parallel-tilstanden og lignende, når vi ønskede at iterere over den samme opgave med en anden input, brugte vi Map-tilstanden Visual Debugging og Auditability: For overensstemmelse og operationer er evnen til at visualisere hele arbejdsprocessen uvurderlig. Step Functions giver et grafisk overblik over hvert trin, herunder dens input, output og fejlårsager. E. Vedvarende lag (Amazon DynamoDB) Vi valgte DynamoDB som vores kerne database til opbevaring af uforanderlige transaktions- og saldooptegnelser på grund af dens karakteristika, der er afgørende for et massivt kortprogram: 
 
 
 
 Høj volumen, lav latens: DynamoDB er designet til en forudsigelig, enkeltcifret millisekundlatens ved et højt volumen, som er nødvendig for finansielle arbejdsprocesser. Serverless og Managed: Ved at udnytte dens fuldt administrerede karakter eliminerede vi overhead af provisioning, patching og sharding af en traditionel relationel database (MySQL/Postgres), så vi kunne fokusere fuldt ud på udfordringer på applikationsniveau, såsom partition key design. Streams Integration: DynamoDB Streams er afgørende, hvilket giver en næsten realtidsstrøm af ændringer, der udløser downstream compliance, analytics og data warehousing (Snowflake) systemer. Vores forenklede version af vores betalingskortstrømme så sådan ud. I den øverste halvdel dropper den udstedende processor netværksfiler, der er synkroniseret til S3. En EventBridge-regel lytter til nye S3-begivenheder og videresender dem til den udstedende SQS-kæde. Initiator Lambda spørger kontinuerligt denne kø og udløser Network Settlement Step-funktionen, som analyserer netværksopløsningsfilen og gemmer de analyserede data i netværksopløsningstabellen DynamoDB. På den nederste halvdel begynder fintech-flowet, når fintech-partneren dropper transaktions- og balancefilerne. Dette udløser en begivenhed, der ruteres gennem SQS-køen til Initiator Lambda, som derefter starter en separat trinfunktion, der validerer og forsoner filerne mod netværksopløsningsdataene. På højre side har vi FBO-forlig, som forener fintech-balancefilen med det afregnede beløb på FBO-kontoen, for at understøtte end-to-end nøjagtighed på tværs af netværk, fintech og bankoptegnelser. Scaling Battle: Overvinde serverløse grænser Denne arkitektur fungerede godt i starten, men da vores volumen voksede, ramte vi to kritiske flaskehalse: beregningsvarighed og database partitionering, som tvang os til at udvikle vores tilgang. A. Optimering af beregning: Lambda-til-ECS migration Mens filopdeling hjalp, overgik kompleks forsoningslogik over store stykker (f.eks. 20.000 poster i en bred-kolonne, fast-bred-fil) stadig lejlighedsvis dette vindue. Vores løsning var ikke en redesign, men et simpelt arkitektonisk skifte: 
 
 
 
 Unified Codebase: Vi opretholdt en enkelt kerne forligsarbejder, en containeriseret applikation skrevet i Go, som håndterede filparsing og behandling. Dynamisk udførelse: Vi implementerede dette containerbillede til både Lambda (til hurtig, efemeral udførelse) og ECS Fargate (til langvarige, hukommelsesintensive opgaver). Step Function Choice: Step Function bruger en Choice-tilstand tidligt i processen. Hvis filstørrelsen er under en vis tærskel (f.eks. 1 GB), målretter den Amazon Lambda-funktionen. Hvis filen er stor, påberåber Choice-tilstanden integrationen af Step Functions for ECS (RunTask) for at starte en dedikeret Fargate-opgave. Denne tilgang gav os en praktisk balance: Lambda's omkostningseffektivitet og hastighed for 90% af de mindre filer, og Fargate's beregningshovedrum for 10% af de massive, langsomme transaktioner og balancefiler. B. Mastering DynamoDB til high-throughput Writes DynamoDB er et godt valg til en database, der har høje mængder, lav latens krav til transaktionslagring. Men dens skalerbarhed er forudsat på at distribuere I/O ensartet på tværs af partitioner. Throttling opstår, når en enkelt partitionsnøgle overstiger sin grænse (typisk 1000 Write Capacity Units (WCU) eller 3000 Read Capacity Units (RCU) pr. sekund). Vi havde en partitionsnøgle ProgramID#FileDate (f.eks. PROGX#20250101) Dette design mislykkedes, fordi alle transaktioner for et stort program på en enkelt dag ramte overskride WCU grænsen og throttling indtagelse. Find alle transaktioner for et bestemt program på en bestemt dato Samme opdeling The Global Secondary Index (GSI) Backpressure Lesson: Vi forsøgte oprindeligt at løse dette ved at flytte den primære nøgle med høj kardinalitet til en GSI og spørge GSI i stedet. Dette gav imidlertid ingen lindring. Fordi GSI modtager sin datastrøm fra hovedtabellen, hvis den primære tabellens partition allerede er throttled, vil GSI's indtagelseshøje opleve GSI backpressure, hvilket i sidste ende begrænser skriveoverførslen af hele tabellen. Optimeret nøgeldesign: Partition Key Sharding: Vores løsning var at introducere skrive sharding til vores højeste volumen kunder: 
 
 
 
 PK Sharding: Vi tilføjede et beregnet shardnummer til partitionsnøglen: ProgramID#FileDate#ShardN. Sharding Logic: Vi brugte en let hashing algoritme (f.eks. modulo) på TransactionID til at tildele det til en shard (f.eks. resulterer TransactionID % 10 i et shard nummer mellem 0 og 9). Resultat: Dette spredte skrivebelastningen over ti fysiske partitioner i stedet for én, hvilket øjeblikkeligt lindrede hot partition problemet og tillod os at indtaste data med en 10x højere sats. IV. Handlingsmæssige lektioner lært Dette afsnit opsummerer mønstre, som du kan anvende på dine egne forsoningsrørledninger, med eksempler fra vores implementering. A. Systemdesign lektioner Her er tre system design lektioner, du kan anvende, når du bygger en forsoning rørledning, der skal håndtere retries, ufuldkomne input, og flere eksterne systemer: 
 
 
 
 
 
 
 Make retries safe by default (idempotency is the baseline): In an event-driven pipeline, retries are expected, so you should design each step to be safely repeatable. For our use case, we had to pass an idempotency key (for example, a TransactionID or MessageID) through the workflow and use it to guard every side-effecting operation. In practice, that means: 
 
 
 
 Workflow steps: each state transition is protected with conditional writes (for example, in DynamoDB) so the same message cannot advance or mutate state twice. Core banking transactions: postings, transfers, and ledger-affecting actions are executed with explicit dedupe semantics (same idempotency key → same outcome), so a retry results in a no-op or a deterministic “already processed” response rather than a duplicate movement of funds. Webhooks and outbound notifications: These are delivered at least once, so each message includes a stable, recipient-facing idempotency key (event ID) and we maintain an internal delivery ledger (attempts, acknowledgements, and final state). Recipients can safely dedupe replays, and our retries won’t trigger duplicate downstream actions. 
 
 Always Use a Dead Letter Queue (DLQ):   and a redrive policy so that malformed messages are quarantined instead of endlessly retrying and clogging the queue. Configure a SQS DLQ 
 
 Do not let a service be the only source of truth for its own correctness.: Reconciliation is cross-system by definition, so build checks that validate invariants from the outside. For example, comparing transactions sent by the program against the network and their FBO was very important. Konfigurer en SQS DLQ B. Operational Excellence Lektioner Disse operationelle lektioner handler om at reducere tid til at opdage og tid til at løse ved at gøre fejl synlige, håndterbare og nemme at undersøge for både dit team og dine partnere. 
 
 
 
 
 Fokus på intern observabilitet: Vi fandt, at en kultur af observabilitet er overlegen end konstant debugging. Vores fokus skiftede fra at reagere på fejl til at forhindre dem, hvilket krævede operationel disciplin på tværs af bordet. Nøglen til dette var at identificere vores hotspots tidligt (sætte strenge advarsler og tærskler for metrikker som SQS kødybde og DynamoDB throttling) ved at indstille krævede Service Level Objectives (SLO) Fokus på ekstern observabilitet: Du bør gøre forligsfejl håndterbare for klienter ved at returnere klare, selvbetjenende fejlmeddelelser og vejledning.I vores implementering standardiserede vi fejlkoder og overflader tilstrækkelig kontekst for partnere til at løse fælles problemer uden en støtte eskalering. Invester i værktøjer: Opbyg undersøgelsesværktøjer tidligt, så du kan spore mismatches til kildefilen, behandlingen kører, og den resulterende skriver uden at grave gennem logs. Fokus på hastighed for at få feedback: Du bør optimere for hurtige feedback-løb. Serverless aktiverede hurtige lanceringer og lave udviklingsomkostninger. Efter vores første måned med at køre dette begivenhedsdrevne forligssystem var vores samlede cloud computing-regning mindre end vores holds frokostregninger. Denne arkitektur gjorde det muligt for vores lille team at iterere hurtigt og fokusere helt på den komplekse finansielle logik i stedet for på infrastruktur. C. Interface Design: Fil vs. API En almindelig fejl var standard til filbaserede grænseflader, når en API var bedre egnet til forretningsprocessen. 
 
 
 Brug den rigtige grænseflade til problemet: Der er ikke det rigtige svar her; du skal tænke gennem, hvad den rigtige abstraktion er for at løse problemet. Vi brugte kun filer til faktiske batchoperationer, hvor slutdags snapshot er kravet (f.eks. Netværksafvikling). Vi brugte derefter API'er til alt andet, især hvor der kræves realtidsfeedback eller små, diskrete dataoverførsler. Vi måtte omskrive flere interne grænseflader fra filbaserede uploads til HTTP API'er, fordi den operationelle overhead af sporing, behandling og debugging af mange små filer viste sig at være langt mere kompleks end et simpelt API-opkald. Behandl filsystemer som versionskontrakter: Du bør behandle filsystemer som versionskontrakter, fordi små ændringer kan bryde parsing og stille skævt skrue op for forligsresultaterne. Konklusionen At opbygge et forligssystem, der skaleres på AWS, handler mindre om at vælge serverløse komponenter og mere om at designe til fejl, replay og undersøgelser.I vores implementering gav AWS serverløse tjenester et stærkt fundament for orkestrering og holdbar tilstand.

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Denne lyd er produceret på historiens originalsprog!

Lektioner om forsoning på skala med serverløs arkitektur

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Sentry: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet HubSpot: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Sentry: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet HubSpot: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps