Support ticketing and chat may appear to be one mobile feature, but they solve different architectural problems.
A ticket manages workflow: ownership, priority, assignment, escalation, and resolution. A conversation manages communication between authorized participants.
Combining both into one message model becomes difficult once the system needs internal notes, agent transfers, attachments, audit history, or controlled state transitions.
Durable State Must Be Authoritative
The reliable message path is:
Client command → authorization → durable commit → acknowledgement
WebSockets can distribute committed messages with low latency, but they should not be the only delivery path.
After reconnecting, the mobile application should synchronize from its last durable cursor. Push notifications should act only as synchronization signals because they may be delayed, collapsed, throttled, expired, or omitted.
Design for Safe Retries
Every retryable ticket or message command should include a client-generated identifier.
The backend should:
- Enforce uniqueness within the correct user or conversation scope
- Reject reuse of the identifier with different request data
- Return the existing result when a valid retry occurs
- Commit the message and its outbox event together
The outbox removes the gap between committing business data and recording publication intent. Its relay and consumers still require monitoring, retries, and duplicate handling.
Keep Ticket and Message State Separate
A message should not silently resolve, reopen, or assign a ticket.
Ticket changes belong to an explicit state machine with authorization and concurrency controls. Internal agent notes must also be excluded through server-side visibility rules rather than hidden only in the customer interface.
Treat Attachments Independently
Attachments need their own upload and processing lifecycle.
The backend should independently verify ownership, upload completion, size, detected content, and processing status. Access should remain restricted until the required validation and scanning have completed.
Build for Reconciliation
The most useful reliability property is not uninterrupted real-time delivery. It is the ability to recover consistent conversation history after:
- Network interruption
- Application suspension
- Duplicate events
- Delayed notifications
- Temporary service failure
That requires durable messages, scoped idempotency, server-issued ordering, gap-aware synchronization, observable outbox processing, and explicit failure states on the mobile client.
Top comments (0)