Streams and Event Sourcing
Unlike message queues , streams can retain data for a configurable period of time, allowing consumers to read and re-read messages from a specified time. You can use a stream to ingest high volumes of events in real-time, e.g., real-time analytics of user engagements in social media.
Event sourcing involves storing changes in application state as a sequence of events. These events can be replayed to reconstruct the system’s state at any point in time. The technique is useful for systems that require a detailed audit trail, e.g., a banking system, where every transaction (deposits, withdrawals, transfers) need to be recorded and may affect multiple accounts.
Doesn’t this then mean that the system needs to be backward compatible to the stored sequence of events? The events from 5 years ago should still work[?]
In a real-time group-chat application, when a participant sends a message, it’s published to a stream associated with the group chat. All chat participants are subscribers to the stream, allowing for real-time communication.
There can be different consumer groups on the same stream. In a real-time analytics system, one consumer group might process events to update a dashboard, while another group processes the events to store them in a database.
Distributed Lock
Traditional databases with ACID properties use transaction locks, e.g., when one user is updating a record, no one else can update it. However, there’s need for longer term locking, e.g., when a user is booking a ticket, other users shouldn’t be able to grab it from underneath them.
Distributed locks are based on distributed key-value pairs. Suppose you have a
Redis instance with a key ticket-123. To lock it, set the value of
ticket-123 to locked. If another process tries to set the value of
ticket-123, it’ll fail because the value is already set to locked. Once the
first process is done with the lock, it can set the value of ticket-123 to
unlocked, and another process can acquire the lock.
Locks should be set to expire after a certain amount of time, \(t\). If the owning process dies/crashes, then another process can acquire the lock at time \(t\).
Suppose process \(p_1\) acquires lock \(l_A\) and then tries to acquire lock \(l_B\), while another process \(p_2\) acquires \(l_B\) and then tries to acquire \(l_A\). This leads to deadlock where both processes are waiting on each other to release a lock. A common cause of this is pulling in locks from far-flung pieces of system, making it hard to recognize deadlocks.
References
- System Design Key Technologies. www.hellointerview.com . Accessed Jul 14, 2026.
Contains content that is not extensive enough for its own page.