Socure Software Engineer Interview Experience — Payment Queue Visibility Timeouts and Concurrency Races

Backend/SDE Coding

I recently interviewed for a Backend/SDE role. The coding problem leaned toward backend work and concurrency.

interface PaymentMessageQueue {
    void submit(PaymentMessage message);
    PaymentMessage receive();
    void ack(String messageId);
}

The problem was to implement an in-memory payment queue providing submit, receive, and ack.

Requirements:

submit adds a message.

receive gets the next message.

After a message is received, other consumers cannot get it during the visibility timeout.

ack deletes it.

If the timeout expires without an ack, the message reenters the queue.

I initially used ConcurrentLinkedQueue, with peek() in receive().

The interviewer asked: If two consumers call receive at the same time, could they get the same message?

Yes, because peek() doesn't remove the message. I should use poll(), so that after one consumer takes a message, it is removed from the pending queue.

Then we discussed the visibility timeout.

My idea was to maintain a pending queue and an inFlight map.

receive:

pending.poll() → inFlight.put()

ack:

inFlight.remove()

At first, I considered scanning inFlight on every receive and returning timed-out messages to pending.

The interviewer asked: If inFlight contains lots of messages, would scanning it on every receive affect latency?

Yes, because receive could become O(N).

I then changed it to use ScheduledExecutorService. After a message is received, schedule a timeout task directly. When the timeout expires:

if (inFlight.remove(messageId, message)) {
    pending.offer(message);
}

That way, receive doesn't have to scan all in-flight messages.

After that, we focused on concurrency races.

What if the timeout and ack happen at the same time?

You can't simply requeue first and remove afterward, because the two threads may run at the same time.

Use:

inFlight.remove(messageId, message)

With ConcurrentHashMap's conditional remove, only the thread that successfully removes the current message can continue.

If ack succeeds first, the timeout won't requeue it. If the timeout succeeds first, ack won't handle it again.

The follow-up was: Can this queue guarantee exactly-once processing?

No. A visibility timeout is fundamentally at-least-once delivery.

For example, if a consumer takes longer to process a message than the timeout, the same message may reenter the queue and be processed again by another consumer.

So payment processing itself needs to support idempotency. It can't depend on the queue to guarantee exactly-once processing.

Summary: The code isn't complicated; the main focus is concurrency. The key points are peek versus poll, visibility timeouts, ACK/timeout races, avoiding a full inFlight scan inside receive, and at-least-once delivery and idempotency.

Overall, it was practical. The follow-ups felt more important than the code itself.

Additional note (2026-09-08 07:20 +08:00):

Finding a job isn't easy.