3. Arkitektur & Databas

Ja, som BLOB-data (Binary Large Object), men det rekommenderas generellt att lagra filerna i ett filsystem eller molnlagring (som AWS S3) och endast lagra referenssökvägen/URL:en i databasen.

SELECT * FROM table_name; (Hämta data), INSERT INTO table_name VALUES (...); (Lägg till data), UPDATE table_name SET column=value; (Modifiera data), DELETE FROM table_name WHERE condition; (Ta bort data).

En Function App är händelsedriven — den körs bara när den triggas av specifika händelser (HTTP-förfrågningar, timers, kömeddelanden etc.) och stängs av när den inte används. En Web App körs kontinuerligt. Dessutom kan en Web App exponera en komplett applikation för användaren (både front end och back end), medan en Web Service (eller Function App) vanligtvis bara exponerar back end-logik. En Web App kan också konfigureras för att bara exponera back end, men den viktiga skillnaden är att den alltid är igång.

Relationsdatabaser kännetecknas av ACID-egenskaperna (Atomicity, Consistency, Isolation, Durability), som garanterar tillförlitlig transaktionsbehandling. Icke-relationella databaser kännetecknas istället av CAP-teoremet (Consistency, Availability, Partition Tolerance), som fastslår att ett distribuerat system bara kan garantera två av dessa tre egenskaper samtidigt.

ACID står för Atomicity (Atomicitet), Consistency (Konsistens), Isolation (Isolering) och Durability (Hållbarhet), och dessa är de viktigaste egenskaperna som relationsdatabaser garanterar för transaktioner. För icke-relationella eller distribuerade databaser är det relevanta konceptet CAP-teoremet. CAP-teoremet säger att man i ett distribuerat databassystem inte samtidigt kan garantera alla tre följande egenskaper: Consistency (C) – varje läsning får den senaste skrivningen, Availability (A) – varje begäran får ett svar, och Partition Tolerance (P) – systemet fortsätter att fungera trots nätverkspartitioner. Ett distribuerat system måste välja att prioritera två av dessa tre garantier på bekostnad av den tredje.

Tillämpa principer för clean architecture, specifikt hexagonal arkitektur med ports och adapters. Målet är att hålla domänlagret frikopplat från både ramverket och infrastrukturen. För externa leverantörer som betalningssystem, definiera ports (gränssnitt) i domänlagret och implementera adapters i infrastrukturlagret. För kommunikation mellan tjänster, använd event-driven-mönster: publicera händelser och prenumerera på dem. Detta tillvägagångssätt säkerställer att den centrala affärslogiken förblir oberoende av externa angelägenheter, vilket gör det enklare att byta leverantörer eller ändra infrastruktur utan att påverka domänen.

Det rekommenderade tillvägagångssättet är att implementera Strategy-mönstret för notifikationskanalerna. Varje kanal (SMS, E-post, Push) implementeras som en separat strategiklass. För take-home challenge kan det faktiska utskicket simuleras med ett loggmeddelande som anger att notifikationen skickades via den angivna kanalen tillsammans med relevant data. Huvudmålet är att göra koden utbyggbar så att nya kanaler kan läggas till i framtiden utan att modifiera befintliga kanalimplementationer, i enlighet med Öppet/Stängt-principen.

Node.js hanterar samtidighet naturligt genom sin event loop. För hög trafik skulle jag först konfigurera en load balancer för att skala horisontellt och hantera stor användarbelastning. Sedan implementera rate limiting för att förhindra att en enskild IP gör för många förfrågningar. Använda caching med Redis för att lagra API-svar i minnet. För betalningshantering, utvärdera om vi ska bygga bankkommunikationen själva eller använda en mikrotjänst som följer PCI-standarder genom att tokenisera kort. Om marknaden sträcker sig till Europa, säkerställa efterlevnad av SCA-regler (Strong Customer Authentication), och om banken kräver 3D Secure, visa den prompten för användaren. Använda MongoDB för att lagra transaktionsreferenser och analysera om kunddata bör sparas för prenumerationer eller automatiska kortdebiteringar. Implementera tokenvalidering för säkerhet. Följa Repository-mönstret för att frikoppla affärslogik från databasanslutningar eller extern API-konsumtion. Anta en event-driven-arkitektur för att reagera på händelser som att verifiera om en användare existerar i verkligheten. Använda idempotens för att förhindra dubbla betalningar eller duplicerade användare. Börja med en monolit och överväg bara att extrahera en mikrotjänst för icke-kärnfunktionalitet för att undvika att bryta mot YAGNI-principen.

En viktig strategi är att implementera cache för data som inte ändras ofta. Genom att cacha relativt statisk data minskar du onödiga upprepade förfrågningar eller beräkningar, vilket kan förbättra svarstiderna avsevärt. Andra vanliga strategier inkluderar att optimera databasfrågor, använda index, implementera lazy loading, tillämpa paginering, använda CDN:er för statiska resurser och profilera applikationen för att identifiera flaskhalsar.

Ett tillvägagångssätt är att använda WebSockets för att upprätthålla en persistent, synkron anslutning mellan klienter, med meddelanden ordnade efter publiceringsdatum och -tid. Alternativt kan en meddelandekö som Apache Kafka användas för att säkerställa ordnad och tillförlitlig meddelandeleverans och upprätthålla synkronism mellan producenter och konsumenter. Båda metoderna tillgodoser det grundläggande kravet på att hålla meddelanden konsekventa och i rätt ordning mellan deltagarna.

Viktiga designöverväganden inkluderar: (1) Köbaserad köphantering — placera inkommande köpförfrågningar i en kö för att etablera en rättvis ordning och säkerställa att bara en förfrågan behandlar en given plats åt gången, vilket förhindrar överbookning. (2) Load balancing — fördela den höga volymen av samtidiga inkommande förfrågningar över flera serverinstanser för att undvika en enskild felkritisk punkt och minska latensen. (3) Skalbarhet — designa systemet för att skalas horisontellt (lägga till fler instanser) för att hantera plötsliga trafiktoppar som uppstår när biljetter släpps. Samtidighetskontroller som optimistisk eller pessimistisk låsning på biljettlagerposter är också kritiska för att garantera datakonsistens.

När du designar ett system för att massinfoga 1 miljon poster från en CSV-fil i en SQL-databas, överväg följande tillvägagångssätt: 1. **Undvik ORM**: I den här skalan introducerar ORM-lager onödig overhead. Använd direkt databasåtkomst istället. 2. **Läsning i chunks / buffrat**: Parsa CSV-filen i delar istället för att ladda hela filen i minnet på en gång. 3. **Binär filläsning**: Föredra binär I/O framför textbibliotek för bättre filläsningsprestanda. 4. **Nativ bulk insert**: Utnyttja databasmotorns inbyggda bulk insert-funktionalitet (t.ex. Oracles bulk insert). Detta tillvägagångssätt kan ladda 1 miljon poster på ungefär 50 sekunder. 5. **Datavalidering**: Innan infogning, validera varje rad — datatyper, obligatoriska fält och värdebegränsningar — för att förhindra att felaktigt formaterad data når databasen och för att minimera transaktionsåterrullningar. 6. **Asynkron bearbetning**: Eftersom en nyttolast av den här storleken inte kan hanteras i en enda synkron HTTP-förfrågan, bearbeta filen asynkront och returnera omedelbart ett svar till klienten som indikerar att importen pågår. 7. **Transaktionshantering**: Omslut infogningar i transaktioner och samla de rader som misslyckas (t.ex. på grund av begränsningsöverträdelser) så att de kan returneras till anroparen som en felrapport istället för att avbryta hela operationen. 8. **Batchdelning**: Istället för en enda enorm förfrågan, dela upp arbetsbelastningen i mindre batchar (t.ex. 100 förfrågningar om 10 000 poster vardera) för att förbättra robustheten och hanterbarheten.

CAP-teoremet slår fast att ett distribuerat databassystem inte samtidigt kan garantera alla tre följande egenskaper: Konsistens (C) — varje läsning returnerar den senaste skrivningen eller ett fel; Tillgänglighet (A) — varje förfrågan får ett svar utan fel, dock inte nödvändigtvis med den senaste datan; och Partitionstolerans (P) — systemet fortsätter att fungera trots nätverkspartitioner mellan noder. Högst två av dessa tre egenskaper kan garanteras fullt ut samtidigt. Detta skiljer sig från relationsdatabaser, som styrs av ACID-egenskaperna: Atomicitet, Konsistens, Isolering och Hållbarhet. ACID fokuserar på transaktionsintegritet inom en enskild databas, medan CAP hanterar avvägningar i distribuerade system.

Två huvudsakliga tillvägagångssätt kan övervägas. Först kan man använda WebSockets för att upprätthålla en persistent, synkron anslutning mellan deltagarna och sortera meddelanden efter deras publiceringstidsstämpel. Alternativt kan man använda ett meddelandekösystem som Apache Kafka för att upprätthålla meddelandeordning och säkerställa synkronism mellan konsumenter. Det bästa valet beror på systemets skala och specifika krav.

För NoSQL-databaser i allmänhet bör du studera CAP-teoremet tillsammans med vanliga frågor som är specifika för den kategorin av databaser. För MongoDB specifikt bör du fokusera på: CRUD-operationer (MongoDB Academy erbjuder en kort kurs), aggregation framework, vyer, strategier för dokumentunderhåll, korrekta indexeringstekniker och optimering av frågeplaner (tillvägagångssättet är analogt med relationsdatabaser). Sharding är ett annat viktigt ämne som ofta dyker upp som intervjufråga. För SQL och relationsdatabaser är ACID-principerna det motsvarande grundläggande konceptet att behärska.

Tekniska arkitekturtester för Data Engineering-roller brukar delas in i två kategorier. Den första är av konceptuell typ, där man förväntas förklara hur man skulle angripa dataprocessen och vilka verktyg eller tekniker man skulle använda för att bygga lösningen. Den andra är av praktisk typ, där man behöver producera konkret arbete, som att skriva kod, designa datapipelines, hantera konfiguration, implementera Spark-jobb, bygga datakvalitetsvalidatorer, tillämpa normaliseringstekniker och liknande uppgifter. De specifika leverablerna beror på vilka verktyg och vilken teknikstack företaget använder. Det rekommenderas att studera både den konceptuella sidan (arkitekturmönster, motivering för val av verktyg) och den praktiska sidan (programmering i ramverk som Spark, datakvalitetskontroller, pipeline-design).

Relationsdatabaser kännetecknas av ACID-egenskaperna: Atomicitet (en transaktion behandlas som en enhet — antingen genomförs den helt eller inte alls), Konsistens (en transaktion för databasen från ett giltigt tillstånd till ett annat giltigt tillstånd), Isolering (samtidiga transaktioner körs som om de vore sekventiella, utan inbördes störningar) och Hållbarhet (när en transaktion väl är bekräftad kvarstår den även vid systemfel). Icke-relationella (NoSQL) databaser beskrivs av CAP-teoremet, som säger att ett distribuerat system endast kan garantera två av följande tre egenskaper samtidigt: Konsistens (varje läsning returnerar den senaste skrivningen eller ett fel), Tillgänglighet (varje förfrågan får ett svar, dock inte nödvändigtvis med den senaste datan) och Partitionstolerans (systemet fortsätter att fungera även om meddelanden mellan noder förloras eller fördröjs).

CAP-teoremet säger att ett distribuerat databassystem inte kan garantera alla tre följande egenskaper samtidigt: Konsistens (C) — varje läsning returnerar den senaste skrivningen eller ett fel; Tillgänglighet (A) — varje förfrågan får ett svar, även om det inte nödvändigtvis innehåller den senaste datan; och Partitionstolerans (P) — systemet fortsätter att fungera trots nätverkspartitionering mellan noder. Till skillnad från relationsdatabaser, som strävar efter att uppfylla ACID-egenskaperna, är distribuerade och NoSQL-databaser utformade kring de avvägningar som definieras av CAP-teoremet, vilket innebär att ett system bara kan garantera två av de tre egenskaperna fullt ut åt gången.

De viktigaste AWS-tjänsterna kan sammanfattas enligt följande: - EC2: Hyr virtuella servrar på minuter (hanterade beräkningsinstanser). - S3: Objektlagring — lagra vilken filtyp som helst när som helst. - RDS: Hanterad relationsdatabastjänst — inga serverunderhållsproblem. - Lambda: Serverlös beräkning — kör kod utan att etablera eller hantera servrar. - API Gateway: Exponera backend-API:er säkert för externa konsumenter. - CloudWatch: Övervakning och observabilitet — spåra mätvärden, loggar och varningar för att se vad som går sönder. - VPC: Virtual Private Cloud — ditt isolerade privata nätverk inom AWS. - IAM: Identity and Access Management — definiera vem som får göra vad med dina AWS-resurser. - CloudFront: Content Delivery Network — distribuera innehåll globalt för låg latens. - DynamoDB: Hanterad NoSQL-databas utformad för horisontell skalning utan operativ overhead. - SQS: Simple Queue Service — tillförlitlig, frikopplad meddelandehantering mellan applikationskomponenter. - SNS: Simple Notification Service — sänd ut varningar och notifieringar omedelbart till flera prenumeranter.