This article describes a practical way to reason about that workflow. The ideas apply to any scheduling product, including Confirmatodo, which connects Google Calendar with WhatsApp for appointment confirmations, reminders, rescheduling, and online booking.

Start with a stable appointment identity

The first design decision is the identity of an appointment. A title is not enough because two events can have the same title. A useful record keeps the calendar provider, calendar identifier, event identifier, and a local version or update timestamp. That combination gives the application something stable to compare when the event changes.

The reminder job should also have its own identity. A simple key can combine the appointment identifier, reminder type, and scheduled delivery window. For example, a key might represent the twenty-four-hour reminder for one specific event. If the worker sees that key again, it can safely recognize the delivery as already processed instead of creating a second message.

Make every transition explicit

A useful appointment state model separates what the calendar says from what the messaging system has done. The calendar state might be scheduled, cancelled, or moved. The delivery state might be pending, sent, failed, or superseded. Keeping those concerns separate makes it easier to explain what happened when a user asks for help.

When a calendar update arrives, the application can compare the event version with the last version it processed. Older updates should be ignored. A newer update should invalidate reminders that refer to the old time and create new reminder keys for the new time. This is safer than trying to patch a previously sent message in place.

Treat retries as normal

Network calls fail. A WhatsApp provider can return a timeout even when it eventually accepts the message. A queue can deliver the same job twice. These are ordinary operating conditions, not exceptional cases.

The worker should therefore persist an idempotency key before or alongside the provider request, depending on the provider contract. If the provider supports idempotency, send the same key on retry. If it does not, keep a delivery record and use a short reconciliation process to distinguish an unknown result from a confirmed failure. The important point is to avoid assuming that a timeout means the message was never sent.

Retries should also have boundaries. Store the attempt count, next retry time, and last provider response. Exponential backoff reduces pressure during an outage, while a final failed state gives the team a clear place to investigate. Do not keep retrying a reminder after the appointment has been cancelled or replaced by a newer event version.

Keep the message honest

A reminder should contain the current appointment information and make its purpose clear. If the event was moved, the message should say that the time changed. If the event was cancelled, the system should not send a normal confirmation message. If the customer must choose an action, the message should provide one unambiguous path for confirming or requesting a change.

Time zones deserve special attention. Store the canonical event time with its time-zone information, then render it for the recipient using an explicit zone. Tests should cover daylight-saving changes, midnight boundaries, and locations that do not observe daylight saving time.

Test the workflow as a sequence

Unit tests for a formatter are useful, but the most valuable tests exercise a sequence of events:

1. Create an appointment and schedule a reminder.
2. Process the same calendar update twice and confirm that only one reminder is created.
3. Move the appointment before delivery and verify that the old reminder is superseded.
4. Retry a provider timeout and verify that the idempotency key remains stable.
5. Cancel the appointment and verify that pending reminders are stopped.
6. Reopen the event after a cancellation and verify that a new version gets a new delivery key.

These scenarios expose race conditions that are easy to miss when each function is tested in isolation. They also produce useful operational signals: duplicate-prevention counts, delivery latency, provider failures, and reminders suppressed because an event changed.

A small amount of state creates a more reliable experience

The central idea is simple: appointment changes and message delivery are different streams of state. Give each appointment version and each reminder a durable identity, make retries safe, and stop work when a newer event makes it obsolete. The result is a workflow that is easier to debug and more respectful of the person receiving the message.

For more context on the product direction, visit confirmatodo.com. For the calendar side of the integration, the Google Calendar API documentation is the right place to verify provider-specific behavior.