We all have heard of synchronous and asynchronous systems, but let us talk about an interesting hybrid that gets far less attention - partially synchronous systems.
A partially synchronous system provides timing guarantees during stable periods, but relaxes them during network hiccups, load spikes, or failures. In other words, it assumes that issues will eventually get resolved, and the system will recover.
Hence, partial synchronous behaviour is a design choice, not a compromise. A clear real-world example is Kafka.
During normal operation, Kafka can behave synchronously depending on configuration. With stronger acknowledgment settings like acks=all, producers wait for the leader and in-sync replicas (ISR), giving durability and ordering guarantees.
When failures occur, Kafka does not freeze. Leaders can still accept writes, and if min.insync.replicas is not met, writes are rejected rather than the system hanging indefinitely. This is the trade-off: temporarily reduced guarantees in exchange for availability.
Once brokers recover, they catch up and rejoin the ISR, restoring consistency. A purely synchronous system would block on any failure, while a purely asynchronous one would risk data loss. Neither works well at scale.
Partial synchronous behaviour strikes a balance - strong guarantees on the happy path, graceful degradation during failure, and recovery once the system stabilises. It does add complexity, but it avoids extreme trade-offs.
So the crux is - you do not have to pick a side :) A hybrid approach handles both the happy path and the degraded one.
Hope this helps.