Batch er et specialtilfælde af streaming. Når din virksomhed skal reagere på få sekunder i stedet for timer, har du brug for en arkitektur bygget til kontinuerlig dataflow.

Dine dashboards er forældede, når nogen kigger på dem. Svindeldetektion kører som et natligt batchjob, der opdager svindel den næste morgen. Lagerbeholdninger opdateres hver time, hvilket fører til oversalg. Sensordata indsamles, men der handles ikke på dem, før de er analyseret i en natlig ETL. Du har brug for et system, hvor data flyder kontinuerligt fra kilder gennem behandling til forbrugere med latenstid under et sekund – realtidsanalyse, live-notifikationer, streaming AI-inferens og øjeblikkelig synkronisering mellem systemer.
Explore more design patterns and system architectures
Vores arkitekter kan hjælpe dig med at designe og bygge systemer ved hjælp af dette mønster til dine specifikke krav.
Kom i KontaktRealtids-streamingarkitektur behandler data som et kontinuerligt, ubegrænset flow frem for diskrete batches. Hændelsesproducenter publicerer til en streamingplatform (Kafka, Kinesis, Pulsar). Stream-processorer (Flink, Kafka Streams, custom consumers) transformerer, beriger, filtrerer og aggregerer hændelser undervejs. Behandlede resultater skubbes til forbrugere: realtids-dashboards (WebSocket), søgeindekser (Elasticsearch), analysedatabaser (ClickHouse) og nedstrøms tjenester. Change Data Capture (CDC) gør det muligt for eksisterende databaser at deltage som hændelseskilder uden ændringer i applikationen.
Arkitekturen har fire lag. Hændelseskilder producerer data – applikationshændelser, database CDC-streams, IoT-telemetri, bruger-klikstreams, eksterne API-webhooks. Streamingplatformen (Kafka) tilbyder holdbar, ordnet og genafspilningsbar hændelseslagring. Stream-processorer forbruger fra topics, anvender transformationer (filtrering, berigelse, vinduesbaseret aggregering, joins) og producerer til output-topics eller sinks. Forbrugere abonnerer på behandlede streams – WebSocket-servere skubber til browsere, connectors synker til databaser, alerting engines evaluerer regler og sender notifikationer.
| Lag | Teknologier |
|---|---|
| Streaming | Apache Kafka (MSK, Confluent), Kinesis, Apache Pulsar, Redpanda |
| CDC | Debezium, AWS DMS, Maxwell |
| Behandling | Apache Flink, Kafka Streams, Benthos, brugerdefinerede forbrugere |
| Realtidslevering | WebSocket (Socket.io), SSE, GraphQL Subscriptions |
| Analyse | ClickHouse, Apache Druid, Elasticsearch, TimescaleDB |
| Observérbarhed | Kafka lag-overvågning (Burrow), Flink metrics, brugerdefineret latenstidsporing |
| Brug når | Undgå når |
|---|---|
| Forretningsbeslutninger kræver datafriskhed under et sekund (svindel, overvågning, handel) | Batchbehandling med time- / daglig friskhed opfylder forretningsbehovet |
| Flere forbrugere har brug for den samme hændelsesstream (fan-out, afkoblede systemer) | Du har én producent og én forbruger – en simpel kø er tilstrækkelig |
| Du har brug for hændelsesgenafspilning til debugging, genbehandling eller opbygning af nye forbrugere | Datavolumen er lavt (< 1K hændelser/min) og retfærdiggør ikke streaminginfrastruktur |
| CDC er nødvendigt for at synkronisere eksisterende databaser med nedstrøms systemer uden kodeændringer | Teamet mangler erfaring med distribuerede systemer – streaming tilføjer betydelig operationel kompleksitet |
MW designer streamingsystemer ud fra "genafspilningsprincippet" – hver stream skal kunne genafspilles fra et givent tidspunkt, hvilket gør det muligt for nye forbrugere at fylde historiske data op og for eksisterende forbrugere at genbehandle efter fejlrettelser. Vores Kafka-implementeringer inkluderer skemaudviklingspolitikker (bagudkompatible som standard), advarsler om forbruger-lag (før det bliver en forretningssynlig forsinkelse) og dead-letter topics med automatisk genforsøg. Vi har bygget streaming-pipelines, der behandler over 500K hændelser/sekund til videoanalyse, IoT-telemetri og realtids-dashboards.
Én kodebase, hundredvis af tenants, ingen datalækage — fundamentet for enhver skalerbar SaaS-virksomhed.
MicrocosmWorks anbefaler Kafka til teams, der har brug for multi-consumer replay, lange retention periods og cross-cloud portability, da dens log-based architecture understøtter ubegrænsede consumer groups, der uafhængigt genlæser den samme data stream. Kinesis er det bedre valg, når du ønsker en fully managed service, der er tæt integreret med AWS ecosystem, og dine data retention needs er under 7 dage med færre end 10 consumer applications. Vi evaluerer dine specifikke krav—throughput, retention, consumer patterns og operational maturity—under vores architecture assessment for at give den rette anbefaling.
MicrocosmWorks implementerer exactly-once semantik gennem en kombination af idempotente producere, transaktionelle konsumere og deduplikationslag, der bruger hændelsesfingeraftryk gemt i en hurtig opslagscache som Redis. For Kafka-baserede systemer udnytter vi Kafkas indbyggede transaktionelle API, der atomisk committer konsumeroffsets og producerwrites, mens vi for brugerdefinerede streamingspipelines implementerer outbox-mønsteret med deduplikation hos konsumeren. Vi designer altid konsumere til at være idempotente som et sikkerhedsnet, så selv hvis exactly-once mekanismen har en edge-case fejl, vil genbehandling af en hændelse producere det samme resultat.
MicrocosmWorks leverer typisk end-to-end latenstider på 50-200ms for streaming-pipelines, der inkluderer ingestion, processing og sink writing, med sub-10ms opnåeligt for simplere passthrough- eller filtrerings-workloads ved brug af in-memory stream processors som Apache Flink eller Kafka Streams. De største bidragydere til latenstiden er typisk network hops, serialization overhead og sink write batching, som vi tuner baseret på dine præferencer for afvejningen mellem latenstid og throughput. Under vores arkitekturdesign fastsætter vi eksplicitte latency SLOs per pipeline-trin og bygger overvågningsdashboards, der sporer p50, p95 og p99 latenstider i produktion.
MicrocosmWorks implementerer skemaregistre (typisk Confluent Schema Registry eller AWS Glue Schema Registry), der håndhæver bagud- og fremadkompatibilitetsregler, hvilket sikrer, at producenter kan udvikle deres dataformater uden at ødelægge eksisterende forbrugere. Vi bruger Avro eller Protobuf serialisering med eksplicit skemaversionering, så hver besked er selvbeskrivende og kan deserialiseres, selv hvis skemaet er ændret, siden det blev produceret. Vores CI/CD pipelines inkluderer automatiserede skemakompatibilitetskontrol, der blokerer udrulninger, hvis en foreslået skemaændring ville ødelægge downstream-forbrugere.
MicrocosmWorks anbefaler et minimum på 2-3 ingeniører med erfaring inden for distributed systems, stream processing frameworks og infrastructure automation for at vedligeholde en produktions-streamingplatform pålideligt. For virksomheder, der ikke ønsker at opbygge denne ekspertise internt, tilbyder vi managed streaming platform support til $15-$40/time, hvor vores team håndterer cluster operations, performance tuning og incident response, mens jeres udviklere fokuserer på at bygge stream processing applications. Vi tilbyder også træningsprogrammer, der opkvalificerer jeres eksisterende ingeniørteam inden for Kafka-, Flink- eller Kinesis-operationer over 4-8 ugers engagementer.