Uge 40: Læringsmål

Kenneth H Sørensen
Sep 30
2 min read

Updated: Oct 7

Backend-udvikling og API-design

Mål

Grundlæggende forståelse af message brokers og deres rolle i asynkron kommunikation.
Forstå forskellen mellem point-to-point og publish/subscribe mønstrene.
Introduktion til Kafka som distribueret event streaming-system.

Result

Uge 40: Message Brokers (link)

refleksion ift læring ses nedenfor refleksion ift projektet kan ses i den tilhørende blogpost

Proces

Læse introduktion til message brokers og kommunikationen mellem producers og consumers
Forstå sammenhængen mellem brokers, topics, partitioner og consumer groups
Undersøge forskellen mellem message brokers, message queues og API’er
Læse om Kafka som eksempel på en event streaming-platform

Refleksion

Jeg har fået en grundlæggende forståelse af, hvordan message brokers fungerer som bindeled mellem systemer og muliggør asynkron kommunikation, hvor producer og consumer ikke behøver være online samtidig.

Det mest centrale er forskellen mellem message brokers og message queues, som ofte blandes eller sidestilles.

Message brokers

Systemer, der håndterer asynkron kommunikation mellem services i event-drevne arkitekturer.

De kan implementere forskellige mønstre, bl.a.:

point-to-point
publish-subscribe

Message queues

Én af de mekanismer, som en broker kan bruge til at implementere point-to-point-mønstret, hvor en besked leveres til én consumer og derefter fjernes fra køen.

Andre mønstre som publish-subscribe distribuerer i stedet beskeder til mange consumers, som det f.eks. ses i Kafka.

Jeg har lært, at Kafka ikke blot er en queue, men et event streaming-system, hvor data gemmes som en vedvarende log.

Det gør det muligt at genlæse historik, distribuere events til mange consumers og skalere horisontalt.

Jeg vil kunne vurdere, hvornår en message broker giver værdi.

Når systemet skal kommunikere asynkront, være løst koblet og skalerbart
Når hændelser skal deles mellem mange services
Når der er behov for at kunne aflæse eller analysere data over tid (historisk data)
Når systemet skal være robust over for fejl og kunne udjævne spidsbelastninger

Samtidig forstår jeg, at teknologier som Kafka er unødvendigt komplekse i små projekter, men giver mening i store systemer, hvor performance og dataintegration er kritisk.

Videre plan

Fortsætte med implementeringen af "Vertical Slice - Use Case 1" i Storage Service
Læse om storage, Azure og alternativer
Undersøge, hvordan Kafka kan bruges i praksis til eventkommunikation mellem services