created at 2022-12-19
Request-response (HTTP) vs. event streaming (Kafka) 정리 글 Use Cases and Architectures for HTTP and REST APIs with Apache Kafka
event streaming 2 Event Sourcing
페이스북같은 경우, 유저 프로파일을 변경했을 때 여러 다른서버들과 연동이 일어난다. 이러한 서버들은 서버 입장에서 바로 유저에게 반환하지 않아도 된다.
Let’s take an example. Consider a Facebook-like social networking app (albeit a completely hypothetical one) that updates the profiles database when a user updates their Facebook profile. There are several applications that need to be notified when a user updates their profile — the search application so the user’s profile can be reindexed to be searchable on the changed attribute; the newsfeed application so the user’s connections can find out about the profile update; the data warehouse ETL application to load the latest profile data into the central data warehouse that powers various analytical queries and so on.
Event sourcing involves changing the profile web app to model the profile update as an event — something important that happened — and write it to a central log, like a Kafka topic. In this state of the world, all the applications that need to respond to the profile update event, merely subscribe to the Kafka topic and create the respective materialized views – be it a write to cache, index the event in Elasticsearch or simply compute an in-memory aggregate. The profile web app itself also subscribes to the same Kafka topic and writes the update to the profiles database.