Messaging

Software Engineering / 22 Sep 2026 / 6 min read

Transactional Outbox Closes the Database-to-Broker Commit Gap

Transactional Outbox Closes the Database-to-Broker Commit Gap A service often needs one operation to change database state and emit a message. An order may become confirmed while an OrderConfirmed event is sent to a broker. Those actions touch separate systems, so two ordinary writes cannot form one atomic commit unless both systems participate in a distributed transaction. The dangerous part is the interval between the writes. Commit the database first and the process can fail before publishing. Publish first and the database commit can fail afterward. Reversing the order moves the failure window; it does not remove it.

Software Engineering Distributed Systems

Software Engineering / 22 Sep 2026 / 6 min read

Dead-Letter Queues Isolate Poison Messages Without Blocking Progress

Dead-Letter Queues Isolate Poison Messages Without Blocking Progress A message consumer usually treats failure as temporary at first. A database may be unavailable, a remote service may time out, or a worker may restart between receiving and acknowledging a message. Retrying is appropriate when another attempt has a reasonable chance of succeeding. Some messages fail for a different reason. Their payload is malformed, a referenced entity can never satisfy a required condition, or the consumer has a deterministic defect triggered by that input. Repeated delivery then consumes capacity without moving the message toward completion. A dead-letter queue gives that failure a separate destination after the normal retry policy is exhausted.

Software Engineering Messaging

Software Engineering / 21 Sep 2026 / 8 min read

Transactional Outbox Closes the Dual-Write Gap

Transactional Outbox Closes the Dual-Write Gap A service often needs one request to change database state and publish an event. The two operations may look adjacent in application code, but they cross different durability boundaries. A database commit can succeed while a broker publish fails, or the publish can succeed before the database transaction rolls back. That split creates a dual-write problem. No ordering of two independent writes can make them atomic by itself.

Software Engineering Distributed Systems

Software Engineering / 21 Sep 2026 / 5 min read

Transactional Outbox Closes the Database-Broker Commit Gap

Transactional Outbox Closes the Database-Broker Commit Gap A service often needs one request to change database state and publish a message. Those actions may look adjacent in application code, but they cross two independent commit boundaries. If the database and broker do not share a transaction protocol, no ordering of two ordinary writes can make them atomic. Consider an order service that stores an accepted order and emits OrderCreated. Publishing after the database commit leaves a crash window before the broker call. Publishing first creates the opposite window: consumers can receive an event for state that later fails to commit.

Software Engineering Distributed Systems

Software Engineering / 20 Sep 2026 / 6 min read

Transactional Outbox Keeps Database State and Events Aligned

A service often needs one operation to change database state and emit an event. An order may move to paid while OrderPaid must reach a message broker. Those two writes cross different systems, so a normal database transaction cannot make both commits atomic. Writing the database first leaves a gap: the process can stop after commit but before publishing. Publishing first creates the opposite gap: consumers can observe an event for a database change that later fails.

Software Engineering Transactional Outbox

Software Engineering / 19 Sep 2026 / 8 min read

Transactional Outbox Couples State Change to Message Intent

A service that updates its database and publishes an event to a message broker crosses two independent commit boundaries. If the database commit succeeds and the broker publish fails, durable state exists without its corresponding message. Reversing the order only reverses the failure: a consumer can observe a message for a state change that never commits. A transactional outbox narrows this gap by placing the application write and a durable message record in the same local database transaction. Publication moves to a separate relay. The pattern does not make the database and broker one atomic system; it changes the boundary so message intent becomes part of the database commit.

Software Engineering Distributed Systems

Software Engineering / 19 Sep 2026 / 6 min read

Android Priority Notifications Are Not VIP Channels

Android Priority Notifications Are Not VIP Channels A pager-style Android application can expose a button labeled VIP channel, but Android does not turn that label into a private radio frequency, reserved cellular bearer, or guaranteed delivery path. What the application can build is a priority policy. A server can classify an event as urgent, request high-priority delivery from Firebase Cloud Messaging (FCM), and post the resulting notification to an Android notification channel with high importance. Those controls operate at different layers, and none of them alone provides pager-like delivery guarantees.

Software Engineering Android

Software Engineering / 14 Sep 2026 / 7 min read

Transactional Outboxes Move Atomicity Into the Database

A service updates an order row and emits an event about that update. If the database commit succeeds but the broker publish fails, durable state says one thing while downstream consumers receive no corresponding message. Reversing the order only moves the gap: a successful publish followed by a failed database transaction exposes an event for state that never committed. The difficulty is not message syntax or retry configuration. It is atomicity across two systems that do not share a transaction. A transactional outbox changes the boundary. The application writes its domain state and a message record into the same database transaction, then a separate relay publishes committed outbox records to the broker.

Software Engineering Distributed Systems

Software Engineering / 14 Sep 2026 / 7 min read

Poison Messages Turn Retries Into Queue Retention

A queue consumer receives a message, rejects it, and receives the same message again. That cycle is useful when the rejection came from a transient condition. It is structurally different when the payload can never be processed by the current consumer. The broker can keep honoring redelivery semantics while the application makes no forward progress on that message. Such a message is commonly called a poison message. The important property is not that it contains malformed bytes. A syntactically valid message can be permanently unprocessable because its schema is unsupported, a required invariant is violated, referenced data can never exist, or application logic deterministically rejects its state.

Software Engineering Distributed Systems

Software Engineering / 13 Sep 2026 / 7 min read

Idempotent Consumers and Durable Duplicate Detection

Idempotent Consumers and Durable Duplicate Detection A consumer commits a database transaction, then loses its connection before acknowledging the message. The broker has no evidence that processing finished, so a delivery protocol that permits redelivery can present the same message again. The second delivery is not evidence that the first transaction failed. From the consumer’s perspective, the important fact is more precise: message delivery and application commit have separate completion points. If the broker cannot atomically participate in the application’s state transition, an acknowledgement can be lost after the application effect is already durable.

Software Engineering Distributed Systems

Software Engineering / 12 Sep 2026 / 7 min read

Transactional Outbox: Moving Publication Across the Commit Boundary

Transactional Outbox: Moving Publication Across the Commit Boundary A service that changes database state and publishes a message has two distinct side effects. A local transaction can make the database change atomic, and a broker can accept the message durably, but those facts do not make the pair atomic. The awkward interval sits between them. If the database commit succeeds and publication does not, durable state exists without the corresponding message. Reversing the order only reverses the exposure: a message can become visible before the database commit succeeds.

Software Engineering Distributed Systems

Software Engineering / 12 Sep 2026 / 9 min read

Transactional Outbox at the Database-Broker Boundary

Transactional Outbox at the Database-Broker Boundary A database commit and a broker publish are two separate state transitions. An application can complete either one first, but unless both systems participate in a common transaction protocol, there is an interval in which one side has changed and the other has not. That interval is the central problem behind the transactional outbox pattern. The pattern does not make a database and broker commit atomically. Instead, it moves the durable publication decision into the same database transaction as the application state change. A separate publisher later converts that recorded intent into a broker message.

Software Engineering Distributed Systems

Software Engineering / 12 Sep 2026 / 11 min read

Idempotent Consumers: Handle Duplicate Messages Safely

Idempotent Consumers: Handle Duplicate Messages Safely A message broker can deliver the same message more than once. A worker may finish its database update and crash before acknowledging the message. The broker sees no acknowledgement, so it sends the message again. From the broker’s perspective, redelivery is the safe choice. From the application’s perspective, the second delivery can repeat a business effect. That gap matters whenever an effect must happen once per logical message. Charging an account twice, granting stock twice, incrementing a counter twice, or sending the same fulfillment request twice can turn a routine retry into corrupted state.

Software Engineering Distributed Systems

Software Engineering / 09 Sep 2026 / 9 min read

Transactional Outbox for Reliable Message Publishing

Transactional Outbox for Reliable Message Publishing A common service operation has to do two things: change its own data and tell another part of the system what happened. For example, an order service may mark an order as paid and publish an OrderPaid message. The awkward part is that the database and message broker usually have separate commit mechanisms. If the service updates the database and then publishes, it can crash between those steps. If it publishes first, the database update can fail afterward. Either order can leave the two systems disagreeing about what happened.

Software Engineering Reliability

Tech / 05 Sep 2026 / 7 min read

Why Photos Can Look Worse After You Send Them

A photo can look sharp in your gallery but softer after you send it through a messaging or social app. Fine text may become harder to read, hair and grass may lose detail, and a picture that originally occupied several megabytes may arrive as a much smaller file. This usually does not mean the camera changed the photo after you took it. The more common explanation is that the sharing service created a different version for transmission or display. It may reduce the image dimensions, compress the image more strongly, or do both.

Photos Image Compression