Automation can make a business process faster and more consistent.
A new order can automatically update stock.
A successful payment can automatically create a receipt.
A completed request can automatically notify the responsible employee.
A new record can automatically start several actions across different systems.
But there is a problem that becomes increasingly important as these processes grow:
What happens if the same event reaches the system twice?
At first, this may seem like a minor technical issue.
It is not.
A duplicate event can result in a customer being charged twice, stock being reduced twice, two messages being sent, or the same request being processed more than once.
The difficult part is that duplicate events can happen even when every system is working normally.
Reliable automated processes therefore need to be designed with this possibility in mind.
Why the same event can arrive twice
Imagine that a payment system tells a company's system that a payment has been completed.
The company's system receives the message and begins processing it.
But before the payment system receives confirmation that the message was successfully handled, the connection is interrupted.
The payment system does not know whether the message was processed.
It sends the same message again.
Now the company's system has received the same event twice.
From the sender's perspective, sending it again is reasonable.
From the receiving system's perspective, the same instruction has appeared twice.
If the system treats every message as a completely new event, it may perform the action twice.
This is why simply saying “process every event” is not enough for a reliable automated process.
The system also needs to determine whether it has already processed that event.
Giving every event a unique identity
One of the simplest ways to solve this problem is to give each event a unique identifier.
For example, an event representing a completed payment might contain an identifier that is unique to that event.
When the system receives it, it can check whether that identifier has already been processed.
If it has not, the system performs the required action.
If it has, the system does not repeat the action.
Instead, it can safely treat the message as a duplicate.
This creates a simple rule:
The same event should produce the same result only once.
The important part is that the system needs a reliable way to recognize the event.
Using only information such as a customer's name or payment amount is usually not enough because different events can have the same information.
The identifier needs to represent the event itself.
Why a simple database check is not always enough
A common implementation is:
Check whether the event exists in the database.
If it does not exist, perform the action.
Save the event as processed.
The problem appears when two copies of the same event arrive almost at the same time.
Both processes may check the database before either one has saved the event.
Both see that it does not exist.
Both continue.
The action is performed twice.
This is why duplicate protection has to be designed as part of the actual operation rather than added as a simple check before it.
The system needs a way to make the check and the recording of the event reliable even when multiple requests arrive together.
The action itself needs protection
There is another important issue.
Suppose the system successfully recognizes duplicate events.
That is useful, but the actual business action must also be handled carefully.
Imagine an automated process that receives an order event and then reduces stock.
If the event is recorded as processed before the stock update succeeds, a failure at the wrong moment can create a different problem.
The system may believe the event was completed even though the actual action never happened.
If it records the event only after the action succeeds, another problem may appear if the action succeeds but the system fails before recording that success.
Reliable automation therefore requires careful handling of both the event and the business action.
Different actions require different protection
Not every automated action has the same risk.
Sending an email twice is annoying.
Charging a customer twice can be serious.
Creating the same employee record twice can cause problems throughout other systems.
Reducing stock twice can create inaccurate inventory.
The design should therefore consider what happens if an action is repeated.
For example, updating a customer's status from “pending” to “approved” may be safe to repeat because the final result is the same.
Adding 100 units to an account balance is different. Repeating that operation changes the result.
This distinction is important when designing reliable automation.
Using a unique record to protect an action
A practical approach is to make important operations depend on a unique business reference.
Suppose an order has a unique order reference.
When the system receives an event to process that order, it can use the reference to ensure that the relevant operation cannot be created twice.
This is particularly useful for actions such as:
Creating an invoice
Recording a payment
Creating a shipment
Creating a maintenance request
Creating an employee account
Updating inventory
The database can enforce the uniqueness of the reference rather than relying only on application code.
This gives the process another layer of protection.
What if the process stops halfway?
A reliable automated process also needs to consider partial completion.
Imagine that an order event triggers three actions:
Update stock
Create an invoice
Notify the customer
The first action succeeds.
The second action succeeds.
The system then stops before sending the notification.
When the process starts again, it should not blindly perform all three actions again.
The system needs to know which work has already been completed.
This can be handled by recording the state of the process and designing each action so that it can safely be retried.
The key idea is that a temporary failure should not force the entire process to start from the beginning.
Retrying is part of reliable automation
Failures are unavoidable.
A remote service may be unavailable.
A network connection may fail.
A server may restart.
A database may temporarily reject a request.
For this reason, automated processes often need to retry failed actions.
But retries create another duplicate risk.
If an action succeeds but the system does not receive confirmation, it may try the action again.
This means a retry mechanism must be combined with duplicate protection.
The system should be able to ask:
“Did this action actually happen already?”
If the answer is yes, it should not perform the action again.
This is one of the main differences between a process that merely works under normal conditions and one that is designed to remain reliable when things go wrong.
Keeping a record of what happened
A reliable process should leave behind a clear record.
For every important event, the system should be able to determine:
When the event was received
Which event it was
Whether it had already been processed
Which actions were completed
Which actions failed
Whether an action was retried
What the final result was
This makes problems much easier to investigate.
Without such a record, an employee may see that something happened twice but have no way to understand why.
With a clear record, the company can identify whether the cause was a repeated event, a retry, a system failure, or an error in the process itself.
Designing around failure instead of assuming success
A common mistake when building automated processes is designing only for the successful path.
The process is imagined as:
Event arrives → action happens → process finishes.
Real systems are not that simple.
A more realistic process is:
Event arrives → action starts → something may fail → the action may need to be retried → the event may arrive again → the system must still produce the correct final result.
Designing for these conditions from the beginning makes the automation much more reliable.
It also makes future changes easier because the process already has clear rules for handling unexpected situations.
Where duplicate protection matters most
Not every automated process needs the same level of protection.
The highest priority should usually be given to actions that have a direct business or financial effect.
Examples include:
Payments and refunds
Inventory changes
Customer account changes
Employee records
Invoices
Orders
Delivery requests
Service requests
Access changes
A duplicate notification may be easy to correct.
A duplicate financial transaction may not be.
Understanding the consequences of repetition helps determine where stronger protection is required.
Making automation trustworthy
The real purpose of duplicate protection is not simply preventing a technical error.
It is making automation trustworthy.
Employees should be able to rely on the system without constantly checking whether an action happened once, twice, or not at all.
Customers should not have to contact a company because an automated process charged them twice.
Managers should be able to trust inventory and financial records.
Maintenance teams should not receive several identical requests because the same machine event was repeated.
Reliable automation is therefore not just about reducing manual work.
It is about ensuring that automated work produces the correct result even when communication problems, retries, and system failures occur.
A better way to design automated processes
When designing a new automated process, the normal successful path should not be the only thing considered.
The design should also ask:
What happens if the same event arrives twice?
What happens if the action succeeds but confirmation is lost?
What happens if the process stops halfway?
What happens if the same action is retried?
How does the system know what has already happened?
Which actions are safe to repeat?
Which actions must never happen twice?
These questions may not be visible to the end user.
They are nevertheless what separates a simple automated workflow from a dependable one.
A well-designed process does not assume that messages will arrive exactly once or that every system will always respond correctly.
It assumes that problems will happen and makes sure the final result remains correct.
That is the foundation of reliable event-based automation.
The goal is not merely to make a process run without human involvement.
The goal is to make it safe to trust when no human is watching every step.