DEV Community: Suprie

Idempotency: Protecting User Intent Beyond the Buy Button

Suprie — Fri, 11 Sep 2026 09:03:36 +0000

User bought some stock but the network is slow. There is no immediate feedback, so out of frustration, they tap the Buy button several times. A few seconds later, multiple orders are matched.

Have you ever got into this situation?

Disabling the button in the UI helps, but it isn't guarantee. UI state changes happen on main thread and depend on when the run loops get a chance to process them. If the main thread is busy, multiple tap events may be handled before the UI visibly transitions into its disabled state.

And even when the UI behaves perfectly, relying on the client alone is dangerous. This is where idempotency comes in.

Idempotency

From Designing Data Intensive Applications:

An idempotent operation is one that you can perform multiple times, and it has the same effect as if you performed it only once.

In our case, what we actually want to protect is the user's intents. If the user intends to buy stock once, we don't want multiple taps, retries, or network issues to accidentally turn that into multiple orders.

But isn't that the backend jobs? Yes, but not entirely. The client needs a way to tell the server: "These requests represent the same intent", while the server needs a way to recognize that intent and ensure it is processed only once.

Idempotency is an end-to-end contract, not just a backend trick

So Who creates the idempotent key and when?

In our case, since we wanted to protect the user intent, it's on the client side. And since it's purpose to protect the user intent, I'm not recommend doing something like

func buy() async {
    let key = UUID()
}

This defeats the purpose. A key is created every time. Instead, I would do something along this:

struct OrderDTO {
    let idempotencyKey: UUID
    let symbol: String
    let side: Side
    let price: Decimal
    let lot: Int
}

@MainActor
@Observable
class OrderFormViewModel {
    var symbol = ""
    var price: Decimal = 0
    var lot: Int 
    var side: Side = .buy 

    private(set) var pendingOrder: OrderDTO?

    func submit() async throws {
        try validate()

        let order: OrderDTO
        if let pendingOrder {
            order = pendingOrder
        } else {
            let newOrder = createOrder()
            pendingOrder = newOrder
            order = newOrder
        } 

        do {
            let orderService = try await orderService.buy(order)
            pendingOrder = nil
        } catch {
            // retry using the pending order
            throw error
        }

    }

    private func createOrder() -> OrderDTO {
        OrderDTO(
            idempotencyKey: UUID(), 
            symbol: symbol, 
            price: price, 
            side: side,
            lot: lot
        )
    }
}

The important is not the UUID itself. It is when that UUID is created and how long we keep it. Once user submits the order, we create an order intent and assign idempotencyKey to it. Any retry with the same intent will reuse the same key.

So even if the user spams the buy button, it will create the order once and then send it to server. The key should only change when the user creates a new intent. For example, after the previous order has completed and they decided to create another one.

If you wanted to more orderly fashion instead of using UUID, which use UUID version 4, you can find some third pary library that generate UUID version 7 which include timestamp

But generating the key on the client is half of the contract. The server still needs to decide what to do when it receives the same key more than once. For example:

POST /order/submit
Idempotency-Key: 01DA...

POST /order/submit
Idempotency-Key: 01DA...

POST /order/submit
Idempotency-Key: 01DA...

The server should not treated them as three orders. Instead it can store the relationship between the idempotency key and the order being processed

01DA... -> Order #1234 -> Pending

When the request arrived with the same key, the server recognized that it has already seen this intent. Rather than creating another order, it can return the existing result:

{
  "order_id": "1234",
  "status": "pending"
}

And if the order has already completed:

{
  "order_id": "1234"
  "status": "matched"
  "payload": {
    ...
  }  
}

Now the responsibility is quite obvious:

The client declares the intent, and the server guarantees that the intent is not executed twice

And that is where things get more interesting on the backend: where do we store the key? How long should it live? What happens if two identical requests arrive at exactly the same time?

That's a topic for the next post.

The Sneaky Coordinator Leak in UIViewRepresentable

Suprie — Mon, 07 Sep 2026 23:36:02 +0000

Let's talk a little about a memory leak I recently found while working with UIViewRepresentable.
The issue happened in a custom UIKit view wrapped inside SwiftUI. At first, nothing looked suspicious. The view worked fine. But after navigating in and out of the screen a few times, the Memory Graph Debugger showed that the Coordinator instances kept increasing.
Here is a simplified version of the setup:

import SwiftUI
import UIKit

final class CallbackButton: UIButton {
    var onTap: (() -> Void)?
    override init(frame: CGRect) {
        super.init(frame: frame)
        addTarget(self, action: #selector(handleTap), for: .touchUpInside)
    }
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    @objc private func handleTap() {
        onTap?()
    }
    deinit {
        print("CallbackButton deinit")
    }
}

struct LeakyCallbackButtonView: UIViewRepresentable {

    @Binding var title: String
    func makeCoordinator() -> Coordinator {
        Coordinator(title: $title)
    }

    func makeUIView(context: Context) -> CallbackButton {
        let button = CallbackButton(type: .system)
        button.setTitle(title, for: .normal)
        // Looks harmless, but this strongly captures the coordinator.
        button.onTap = context.coordinator.handleTap
        return button
    }

    func updateUIView(_ uiView: CallbackButton, context: Context) {
        uiView.setTitle(title, for: .normal)
    }

    final class Coordinator {
        @Binding var title: String
        init(title: Binding<String>) {
            self._title = title
            print("Coordinator init")
        }
        func handleTap() {
            title = "Tapped at \(Date())"
        }
        deinit {
            print("Coordinator deinit")
        }
    }
}

The suspicious line is this one:

button.onTap = context.coordinator.handleTap

It looks like we are only passing a function, but an instance method reference still needs to retain its instance. In this case, the closure stored button.onTap strongly retains the Coordinator.
In a normal UIKit view controller, many people would immediately fix this with [weak self]. But this is UIViewRepresentable.

UIViewRepresentable is a struct, so self is a value type. You cannot use [weak self] the same way you would inside a UIViewController, because weak only applies to class-bound references.

The fix is to weakly capture the Coordinator instead:

struct FixedCallbackButtonView: UIViewRepresentable {
    @Binding var title: String

    func makeCoordinator() -> Coordinator {
        Coordinator(title: $title)
    }

    func makeUIView(context: Context) -> CallbackButton {
        let button = CallbackButton(type: .system)
        button.setTitle(title, for: .normal)
        button.onTap = { [weak coordinator = context.coordinator] in
            coordinator?.handleTap()
        }
        return button
    }

    func updateUIView(_ uiView: CallbackButton, context: Context) {
        uiView.setTitle(title, for: .normal)
    }

    static func dismantleUIView(_ uiView: CallbackButton, coordinator: Coordinator) {
        uiView.onTap = nil
    }

    final class Coordinator {
        @Binding var title: String
        init(title: Binding<String>) {
            self._title = title
            print("Coordinator init")
        }
        func handleTap() {
            title = "Tapped at \(Date())"
        }
        deinit {
            print("Coordinator deinit")
        }
    }
}

There are two fixes here:

button.onTap = { [weak coordinator = context.coordinator] in
    coordinator?.handleTap()
}

This prevents the closure from strongly retaining the Coordinator.
And:

static func dismantleUIView(_ uiView: CallbackButton, coordinator: Coordinator) {
    uiView.onTap = nil
}

This clears the callback when SwiftUI dismantles the UIKit view.
My takeaway:

// UIKit / UIViewController
{ [weak self] in
    self?.doSomething()
}

// UIViewRepresentable
{ [weak coordinator = context.coordinator] in
    coordinator?.doSomething()
}

UIViewRepresentable is a value-type wrapper, but the Coordinator is the reference object that usually carries UIKit-style lifetime and callback behavior. So when a UIKit view stores a closure, be careful not to accidentally retain the Coordinator through that closure.

Just a note for myself.

MVVM vs VIP, which one is the best?

Suprie — Thu, 03 Sep 2026 02:17:28 +0000

The short answer is neither.

There is no silver bullet; no single architecture can fit all codebases. And code, like requirements, is never fixed. It evolves alongside the codebase. What should not drift accidentally are boundaries.

For a greenfield project, I'd start with MVVM. Not because MVVM is inherently better than VIP, VIPER, or any other architecture, but because it's simple enough to start with, many developers are familiar with it, it works naturally with SwiftUI's state-driven model, and if done well, keeps the ViewModel focused on presentation state.

The mistake was thinking that an architecture's name will protect the codebase for you. It won't. A ViewModel can still become a dumping ground for network, persistence, and business rules. If infrastructure details leak into the Interactor or ViewModel, or dependencies are not hidden behind appropriate adapters, the code becomes harder to isolate, replace, and test.

Here's what a bad Interactor looks like:

class LoginInteractor: LoginBusinessLogic {
    let displayLogic: LoginDisplayLogic

    func doLogin(username: String, password: String) {
        Task {
            do {
                guard let url = URL(string: "https://api.example.com/login") else { return }
                var request = URLRequest(url: url)
                request.httpMethod = "POST"
                let (data, _) = try await URLSession.shared.data(for: request)
                let _ = try JSONDecoder().decode(LoginResult.self, from: data)
                displayLogic.showLoginSuccess()
            } catch {
                displayLogic.showLoginFailed(message: error.localizedDescription)
            }
        }
    }
}

struct LoginInteractorTest {

    @Test func testDoLogin() async throws {
        let displayLogic = FakeLoginDisplayLogic()
        let interactor = LoginInteractor(displayLogic: displayLogic)

        interactor.doLogin(username: "abc", password: "abc")

        // doLogin fires a Task internally — there's no way to await it from here.
        // We can't inject a fake result, so this test either:
        //   1. Hits the real endpoint with real credentials, or
        //   2. Races the network call and asserts before it even completes.
        try await Task.sleep(for: .seconds(2)) // guessing how long the network needs
        #expect(displayLogic.isLoggedIn == true) // flaky: fails if the network is slow
    }

}

Compare that to an Interactor that depends on an abstraction instead:

protocol LoginWorker {
    func doLogin(username: String, password: String) async throws -> LoginResult
}

class LoginInteractor: LoginBusinessLogic {
    let displayLogic: LoginDisplayLogic
    let worker: LoginWorker
    func doLogin(username: String, password: String) {
        Task {
            do {
                let _ = try await worker.doLogin(username: username, password: password)
                displayLogic.showLoginSuccess()
            } catch {
                displayLogic.showLoginFailed(message: error.localizedDescription )
            }
        }
    }
}

struct LoginInteractorTest {

    @Test func testDoLogin() async throws {
        let displayLogic = FakeLoginDisplayLogic()
        // Now you can just mock the worker, make it throw any error like succeed,
        // ,failed, or timeout without need to wait for estimated time api call succeed
        // because it never happened
        let worker = FakeLoginWorker()
        let interactor = LoginInteractor(displayLogic: displayLogic, worker: worker)
        interactor.doLogin(username: "abc", password: "abc")

        #expect(displayLogic.isLoggedIn == true)
    }
}

The architecture name matters less than whether the boundaries are actually respected.

The goal was never to reach a specific architecture, the goal is always to make the code understandable as complexity grows.

Dependency direction still matters:

Presentation -> Application / Use Case -> Domain <- Data Infrastructure

That direction defines the boundaries. UI should not know how data is fetched. Business rules should not care whether the data comes from an API, cache, or local DB. Infrastructure should not dictate how the application works.

Those boundaries are more important than whether a type is called ViewModel, Presenter, Interactor, or UseCase. If developers repeatedly struggle to answer questions like:

Where does this behavior belong?
Why does changing this feature require touching unrelated code?
Why do I need to understand five layers to change one screen?
What else breaks if I change this?

Then the current architecture may no longer be doing its job. That's a signal to refactor — not because of hype, but because the existing structure is no longer helping the team reason about change.

For an existing codebase, I'd optimize for incremental boundary improvements rather than introducing a new architecture everywhere. Create seams and the Strangler Fig pattern. The goal is understanding the system, not adopting any particular architecture pattern. Refactoring an existing codebase without understanding it first is like entering the battlefield without joining the briefing. You might know how to fight, but you don't yet know the objective, the terrain, the constraints, or why the current position exists.

Ugly code sometimes contains important business knowledge, or a workaround from a production incident years ago. Duplication may be accidental, or it may represent behavior that diverged for a reason. Before replacing the architecture, understand the system.

For a legacy codebase, the process is closer to:

Understand -> Test -> Find seam -> Replace -> Reassess

rather than

Choose architecture -> Rewrite

Testability is another important part of this. Architectures like MVVM and VIP often trade some delivery speed for clearer responsibilities, predictability, and easier testing. But testability only matters if you actually make use of it. Architecture can tell you where responsibilities belong. Tests tell you what the system is expected to do. That distinction becomes critical over time. Three months after a feature ships, someone will start wondering: "Is this intentional, or a bug?" A good dependency graph can't answer that, but more often than not, a good test can.

Consistency helps make reviews, debugging, onboarding, and refactoring easier. But it's not the goal by itself. The goal is a system the team can understand and change safely.

The best architecture is not the one with the most rules. It's the lightest structure that preserves your system's boundaries, and still lets the team change the code with confidence.