I realised that checkpointing our (message) processing is similar to using cheat codes in Super Frog and similar old games.We need to recover and use the code to get where we were. Of course, sometimes that means going through the half of the level again, but well, better than from the beginning.I also shared with you implementation based on the PostgreSQL how to do it, and how checkpointing can also help in a generic idempotence check (with caution) and to detect noisy neighbours (with understanding).

Architecture Weekly's publication is a central hub for architecture enthusiasts, offering insights into architectural design, urban planning, and sustainable architecture practices. Through articles, case studies, and architectural critiques, Architecture Weekly offers insights into iconic buildings, architectural trends, and innovative design solutions. Readers can learn about architectural history, design principles, and environmental sustainability initiatives to gain a deeper understanding of the built environment and its impact on society. Additionally, Architecture Weekly provides updates on the latest architectural projects, design competitions, and industry events to help architects and designers stay informed and inspired.

Architecture Weekly

Checkpointing in message processing works like save codes in old video games, allowing systems to resume from a specific point after failure. The article demonstrates implementing checkpoints using PostgreSQL with an outbox pattern, storing processor positions and transaction IDs to maintain global ordering guarantees. A stored procedure handles checkpoint updates with optimistic concurrency control, returning different codes to detect idempotent operations and competing processors (noisy neighbors). The approach requires global ordering and benefits from transactional capabilities, trading some performance for correctness and resilience in message processing systems.

Checkpointing the message processing