A fetched ticket, the currently selected ticket, an authenticated user, an editable reply, and a search value are all “state.” They still need different owners. The server owns the saved ticket. Navigation identifies the selected ticket. The user controls the unfinished reply. A search value may be temporary input or a committed view that a link should preserve.

A support agent moving from reading a conversation to generating, editing, and sending a reply crosses several of those boundaries on one screen. Choosing a global-state library first skips the harder questions: who can change each value, how long should it survive, and what makes it authoritative?

My AI Support Assistant provides a concrete example. Its React and TypeScript frontend uses Context for the current session, TanStack Query for ticket and message data, React Router for navigation, and component state for editable forms. Shareable search and filter controls are a proposed addition. The useful architectural lesson is how these responsibilities fit together, including the boundaries I still need to strengthen.

In Frontend System Design: How I Would Architect a Production Dashboard in React, I considered the broader dashboard architecture. Here I want to isolate one question: how should state ownership be divided inside it? I start with ownership, lifetime, and source of truth, then choose the mechanism that fits each responsibility.

2. Start With Ownership, Not Libraries

I start by asking where a value comes from. Is it an authoritative server record, a user's unfinished input, a navigation choice, or a computation over other values? Then I ask what should happen when the component unmounts, the route changes, the browser reloads, or the account changes.

Scope and lifetime are different. A value can be needed by several sibling components while still belonging only to one screen. Conversely, a small user object can have an application-wide session lifetime. “Several consumers” is a reason to share access; it does not automatically justify permanent global ownership.

This is a decision aid, not a rule that every value has exactly one physical representation. A server response can seed an editable form. What matters is whether the form is an intentional working copy or an accidental competing source of truth.

Persistence also deserves its own decision. Putting state in Context does not make it survive reloads. Putting a draft in localStorage would add retention requirements. Putting it in the URL would make it visible in links and history. I would choose those behaviors explicitly instead of inheriting them from whichever storage mechanism is convenient.

Current implementation: which owner supplies which state?

AuthProvider: user + bootstrap status ──> protected UI + computed role checks
URL: screen + ticket ID ────────────────> navigation + query identifier
Server records ──> TanStack Query ──────> ticket/message views + computed metrics
AI suggestion mutation ──> page handoff ──> editable local composer
Local forms ───────────────────────────> unsaved values + validation errors

3. Local State: Keep Ephemeral UI Close to Where It Changes

MessageComposer owns its content, validation error, and submission error with useState. Its pending indicator comes from the message mutation. That distinction is useful: the text is editable UI state, while the request lifecycle already has an owner.

Excerpt from MessageComposer.tsx:

const [content, setContent] = useState(initialContent);
const [fieldError, setFieldError] = useState<string | undefined>();
const [submitError, setSubmitError] = useState<string | null>(null);

const isSubmitting = createMessageMutation.isPending;

The component validates the text, submits trimmed content, and clears the input after the mutation succeeds. A failed submission sets an error without executing that success reset. The textarea is disabled while the request is pending. There is no need to put each keystroke into the message query cache: it is not yet a saved message.

The ticket creation form follows the same boundary. It owns title, description, field errors, and a submission error locally. After successful creation, it navigates to the returned ticket's detail route. The unsaved form and the saved ticket are related, but they have different lifetimes and authorities.

Local does not mean “must live in the smallest possible component.” The AI reply handoff uses state in TicketDetailPage because the suggestion panel and composer are siblings. That parent is the nearest place that coordinates their interaction. Sharing within a screen does not require sharing across the whole application.

For a future dialog or temporary UI toggle, I would begin with the same ownership test: does another screen need to retain or control it? A form that must survive several routes may deserve a longer-lived owner. Component-local storage is a fit for these current forms, not a universal rule for every form.

4. Context: Give the Session a Shared Owner

AuthProvider owns a nullable user and authentication bootstrap loading. The user shape contains id, name, email, and a role of CUSTOMER, AGENT, or ADMIN. The Context exposes that user, login, logout, and isLoading. It does not contain ticket lists or message arrays. Context could expose server data in another design, but providing access does not by itself define fetching, freshness, or reconciliation. Here those responsibilities belong to the query layer.

The token has a separate persistence boundary: the storage service reads and writes access_token in localStorage. At startup, a stored token triggers fetchCurrentUser, which calls /auth/me. A successful response establishes the user in Context; a failure removes the token and clears the user.

Simplified excerpt from AuthProvider.tsx; the surrounding token check and loading handling are omitted:

try {
  const currentUser = await fetchCurrentUser();
  setUser(currentUser);
} catch {
  storage.removeToken();
  setUser(null);
}

Login has two steps across this boundary. The auth service saves the response token, and the login page passes the returned user to Context before navigating to the dashboard. Context's login function itself sets the user and ends loading. A stored credential and the resolved user are complementary session representations, not two interchangeable user databases.

There is also a temporary login mutation result containing the response user. I would not describe authentication as having literally one object representation. The important current boundary is that protected routes and dashboard consumers read the session through Context rather than maintaining a second durable user store.

ProtectedRoute waits for bootstrap, redirects when there is no user, and otherwise renders its nested outlet. Axios reads the token for Bearer authentication. On a 401 it removes the token and redirects to login, except that /auth/me failures are left to bootstrap handling.

Role-derived booleans control which UI actions appear. For example, the detail page computes management access from the user's role. That is presentation logic, not the final authorization boundary: the backend status route independently requires an agent or admin role. Context makes identity available; it does not make the browser authoritative over permissions.

5. TanStack Query: Server State Is Not Just Global Client State

A shared ticket array is only part of the problem. The frontend also needs to know whether it is loading, whether a request failed, which request parameters produced it, and what a successful mutation makes outdated. Sharing access across components does not transfer authority from the server to the browser. These concerns explain why ticket and message records belong in a query cache here.

The application's QueryClient has these defaults:

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 1,
      staleTime: 1000 * 60,
      refetchOnWindowFocus: false,
    },
  },
});

This config expresses a freshness policy; it does not promise continuous synchronization. The application uses a 60-second freshness window and disables window-focus refetching. That interval is not a polling schedule or proof that another agent's changes will appear immediately. The ticket and message views expose loading/error states and retry or refresh behavior instead of treating cache presence as sufficient evidence of freshness.

Ticket keys distinguish list queries, including their parameter object, from detail queries keyed by ticket ID. Message keys distinguish conversations by ticket ID. useTicket and useMessages enable their queries only when the identifier is truthy.

Excerpt from useTickets.ts:

export function useTickets(params?: TicketListParams) {
  return useQuery({
    queryKey: ticketKeys.list(params),
    queryFn: () => getTickets(params),
  });
}

The same parameters define the cache identity and the API request. That alignment matters: two differently filtered requests should not silently share one list entry. It also creates a natural place for future normalized URL parameters to feed the fetching layer.

Mutation reconciliation is explicit. Ticket creation invalidates list queries. A status update patches status and updatedAt in an existing detail entry, then invalidates the lists and that detail. Message creation appends the returned message to the matching conversation cache on success.

The inspected list and thread render query data directly; they do not copy those arrays into component state or Context. This keeps the query result as the frontend's shared representation of the server response. It does not eliminate every consistency question: different cache entries can represent overlapping records, so mutation handling still needs to account for the views affected by a change.

6. URL State: If Navigation Should Preserve It, Consider Putting It in the URL

Selected ticket identity is already navigation state. The active router declares /dashboard/tickets/:id, and the detail page derives its query identifier from that parameter:

const { id } = useParams();
const ticketId = id ?? "";

A ticket link therefore carries the selected identity without requiring a separate selected-ticket store. Browser navigation can change that identity through the pathname, and a direct link identifies which record to request, subject to authentication and access. This does not imply that browser history restores an unsent composer draft.

Current implementation. The list/dashboard behavior is narrower than a full URL-backed search interface. TicketsPage calls useTickets() without parameters and has no filter, search, sort, or pagination controls. The dashboard requests fixed parameters: page 1 and limit 100. The ticket parameter type supports status, priority, search, page, and limit, but that API capability is not an implemented navigation UI.

There is no useSearchParams or URLSearchParams usage in the inspected frontend source. The missing piece is a navigation design for future shareable list controls, rather than migrating existing component-only controls.

How I would evolve it. If list filters, search, and pagination become navigation-relevant, I would put their committed values in URL search parameters. A link such as /dashboard/tickets?status=OPEN&page=2 would describe which view to request after a refresh, when opening a shared link, or when moving back and forward through history. It would preserve the selection criteria, not freeze the server results. Parsing should validate enum values and normalize page numbers before producing query parameters. Changing a filter should deliberately decide whether to reset the page.

Search adds a useful distinction. Text currently being typed can remain local while a committed search becomes URL state. History updates should reflect meaningful navigation rather than creating an entry for every keystroke. Composer content, credentials, and transient errors have no comparable reason to appear in the URL.

7. A Real Workflow Shows Why State Changes Ownership

The message workflow makes the boundary concrete. Before submission, the text belongs to the composer. During submission, the mutation owns pending/error request state. After server success, the returned message becomes part of the conversation cache and the thread renders it.

Excerpt from useCreateMessage:

onSuccess: (newMessage) => {
  queryClient.setQueryData<Message[]>(
    messageKeys.ticket(ticketId),
    (existing) => (existing ? [...existing, newMessage] : [newMessage]),
  );
},

This is a cache update after success, not a speculative optimistic message insertion. The composer waits for mutateAsync before clearing text and invoking its callback. The server-returned record, rather than the raw input string, is what enters the message cache.

The callback increments a page-local messageRefreshToken. Despite its name, MessageThread uses it in a scroll effect alongside message count; it does not refetch messages because the token changed. That small detail matters when explaining ownership: the cache supplies conversation data, while this counter coordinates a UI effect.

Current workflow: when does a draft become a conversation record?

Ticket identity + query-backed view
  -> separate suggestion request [mutation pending/error/result]
  -> returned suggestion [candidate text; not sent]
  -> click Use Reply [page-local handoff]
  -> editable composer [local draft; human may edit]
  -> explicit Send [message mutation]
       success -> returned server message -> query cache -> rendered thread
                  clear composer + signal scroll
       failure -> retain input + show submission error

The same send boundary applies to a reply typed without an AI suggestion.

The AI workflow starts with a separate mutation. ReplySuggestion requests generated text, displays mutation loading/error/result state, and derives a trimmed suggestion and a visibility boolean. It resets that mutation when the ticket ID changes. Generating a suggestion does not call the message creation hook.

Only clicking “Use Reply” invokes the parent callback. The page saves the suggestion as composerDraft and increments composerKey, remounting the composer so its local content initializes from that draft. The user can then edit the textarea and explicitly send through the ordinary message workflow.

This is an intentional working-copy boundary: generated text is a candidate, editable content is the human's draft, and a successful send returns a conversation record. Similar strings across these stages do not have identical authority. I would preserve that separation even if the implementation later changes how siblings exchange the draft.

The current handoff also has a tradeoff. The page retains a seed value while the composer owns the live edited text. Using another suggestion remounts the composer and replaces its local input. I would consider an explicit replacement confirmation or a clearer draft ownership API if preserving unsent edits becomes a requirement. Neither protection is implemented by the shown handoff.

8. What About Redux?

Redux and Redux Toolkit are not used in this frontend: there are no matching source imports/usages or dependencies in its package manifest. The current flows use Context, queries, route identity, component state, and mutation state without a Redux store.

These ownership requirements do not automatically require Redux. A dedicated client store becomes worth considering when there is a coordination problem that the existing owners cannot express cleanly; this implementation alone cannot settle that decision for another product or future workflow.

I would consider a dedicated client store for a cross-feature workflow that stays active across routes, long-lived unsaved work spanning several screens, or coordinated UI transitions with explicit state-machine-like rules. For example, a future multi-ticket response workspace might need draft identity and transitions beyond a single composer. That is a hypothetical requirement, not an existing feature.

Even then, I would define what the store owns before adding it. It might own selected workspace items and unsaved drafts while querying authoritative ticket records separately. Copying every fetched ticket into the new store would introduce synchronization work without proving that the workflow needs it.

9. The Failure Modes I Would Watch For

Current limitations. Two session/cache boundaries deserve priority. First, ticket and message keys contain no account or session identifier. Second, logout removes the token and user but does not explicitly clear the query cache. The module-level QueryClient wraps AuthProvider, so the normal logout button does not recreate it.

Together, those choices leave an account-transition isolation gap. A later login in the same application lifetime can address keys used by the previous session. That is a source-supported isolation risk, not a reproduced data leak. Freshness configuration cannot substitute for session isolation.

How I would evolve it. I would design logout cleanup and account-scoped query identity together, including cancellation of requests that could complete after the session changes. Clearing existing data is only part of the lifecycle. Which requests may still write, and which identity the next request uses, also need explicit answers. This is proposed work, not current behavior.

Other current boundaries. The AI handoff replaces local input when another suggestion is used; draft-preservation behavior would need an explicit design. A separate constraint is the dashboard's derived metrics. They count the returned page-1 list capped at 100 requested tickets. The computation marks possible truncation when the returned count reaches that limit. These are summaries of fetched records, not verified complete account totals. Derived state can be internally correct while its input is incomplete.

General failure modes. Copying query arrays into Context or local state and storing computed permissions independently create values that must stay aligned with their sources. Globalizing transient forms extends their lifetime and coordination surface. Keeping a navigation-relevant selection only in a component prevents the URL from describing it. These are design risks to watch for, not findings that all exist here. An intentional editable snapshot can justify duplication; an unedited mirror usually needs a stronger reason.

10. The State Ownership Model I Would Use as the Dashboard Grows

I would retain the existing division and strengthen the boundaries where behavior is incomplete. The target model below distinguishes retained choices from proposed additions.

Derived values already have useful examples. The detail page computes management permissions from the user role; the dashboard computes metrics and a five-item recent slice from query data with useMemo. The suggestion panel computes whether usable text is present from its mutation result and status. None needs an independently writable global field merely to make consumption convenient.

As the dashboard grows, I would review a new feature by walking through its transitions. What exists before the request? What changes on failure? What becomes authoritative on success? What should survive navigation, reload, or account change? Those questions expose ownership gaps earlier than asking where to put a new boolean.

11. Closing

My working model is to keep unfinished edits close to the UI, share session identity through a session layer, cache server records with explicit reconciliation, and let navigation own the choices a link should preserve. Compute values whose sources already exist. Add a client store when a concrete workflow needs a longer or broader lifetime.

For each new value, I would write down its source of truth, its consumers, and the event that ends its lifetime. Then I would decide whether navigation should preserve it and whether it can be computed from existing inputs. If those answers are unclear, choosing a more powerful store will only move the ambiguity. Resolve the ownership first; the tool choice follows.

Originally published on my engineering blog: https://blog.ramjwork.in/frontend/react-state-architecture

I use the React frontend of my AI Support Assistant as a reference. It has authentication, a dashboard, tickets, conversations, and AI reply suggestions. The code shows a useful set of boundaries and also where those boundaries need more definition. This article distinguishes what the application implements today from what I would change as it grows. The title describes a design goal, not a claim about production traffic or measured scale.

Start with boundaries, not components

Before choosing component sizes, I decide where navigation, identity, data access, and interaction state belong. In the current app, main.tsx mounts shared providers and the router. The router selects pages, AppLayout provides the authenticated shell, feature hooks connect UI to domain queries and mutations, and feature API modules use a shared Axios client.

For ticket reads, the current flow is:

Router -> Page -> Feature hook -> TanStack Query
       -> Feature API -> Shared Axios client -> Backend

This keeps request construction and authentication headers out of the page. It does not remove every dependency: dashboard metrics build on ticket hooks, and message UI reuses ticket error helpers. Those are manageable now, but I would watch cross-feature imports as the application expands.

The repository already groups auth, tickets, messages, and AI by feature. Dashboard hooks and components are also grouped, though the dashboard page remains in src/pages. The active router is src/routes/AppRouter.tsx; an src/app/router.tsx file is empty. I would consolidate those entry points before adding more folders.

State ownership is the central decision

The current frontend keeps tickets and messages in TanStack Query, identity in auth context, ticket identity in the route, and editable form fields in component state. Each has a different authority and lifetime. Treating them as one undifferentiated global store would make synchronization harder to reason about.

Server data  -> TanStack Query
Session      -> AuthProvider
URL          -> Router / search parameters
Transient UI -> Component / feature coordinator
Shared state -> Only for a demonstrated cross-feature need

I promote a value only when another feature truly needs it, it must survive navigation, or there is a clear owner beyond its current component. If two neighboring components need a draft, their coordinator may be enough. Persistence also has several meanings: a value may survive a render, a route change, a reload, or a new login. Those are separate requirements, not reasons to put everything into the same store. Dashboard counts are derived from fetched tickets rather than stored as a second editable copy; the trade-off is that the chosen dataset limits the accuracy of those counts.

The same test helps with filters. A dropdown selection being shared by two components does not automatically make it application state. If the user expects to copy the URL, return with Back, or reload and see the same result, the committed filter belongs in navigation state. If it is simply a temporary draft before pressing Apply, local state is a better fit. I would avoid synchronizing two writable copies of the same filter because one will eventually lag the other.

Routing, shell, and access boundaries

Current implementation: /, /login, and /register are public. Dashboard, ticket list, create, and detail routes are nested under ProtectedRoute and AppLayout. The guard waits for auth bootstrap, redirects when there is no user, and otherwise renders its outlet. It checks identity, not role. The create page separately redirects non-customers; ticket detail controls check roles before showing status management or AI replies.

The shell owns navigation, the user name, logout, and the nested page outlet. Pages own workflows and data. I would keep domain queries out of the shell so every authenticated route does not inherit unrelated fetching.

How I would evolve it: make route requirements explicit as route count grows, preserve a requested destination through sign-in, and provide a deliberate unknown-route page. The active router has no wildcard; the test helper does. This is a small example of how test composition can drift from the application.

Authentication establishes identity; it does not authorize each resource action. The current AuthProvider owns user and loading state. If a stored token exists, it fetches /auth/me; any bootstrap error clears the token and user. The essential current behavior is:

      try {
        const currentUser = await fetchCurrentUser();
        setUser(currentUser);
      } catch {
        storage.removeToken();
        setUser(null);
      } finally {
        setIsLoading(false);
      }

Login and registration persist the returned token, set the user in context, and navigate to the dashboard. Logout clears the token and user. The broad bootstrap catch treats a temporary network failure like an invalid session. I would distinguish those outcomes and define what happens to in-flight requests during logout or account switching.

The UI hides or shows actions by role, but that is presentation. The inspected backend routes restrict ticket creation to customers and status changes to agents/admins. Ticket access is scoped by customer ownership or agent assignment, and the service rechecks access for cached tickets. The AI suggestion route also has an agent/admin gate. These checks show the authority boundary; they are not a full security audit. For a larger UI, I would centralize capability predicates to keep repeated presentation rules consistent, while leaving authorization decisions on the server.

Server state, cache consistency, and the API boundary

The current TanStack Query defaults are one retry, a one-minute stale time, and no refetch on window focus:

export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 1,
      staleTime: 1000 * 60,
      refetchOnWindowFocus: false,
    },
  },
});

Ticket keys distinguish lists and details; message keys distinguish conversations by ticket id. Detail and message queries require a nonempty id. Feature API modules unwrap response data and return domain values. Stale time is a freshness policy; it does not make remote changes arrive immediately.

There is a meaningful session boundary to improve: the ticket and message keys do not include account identity, and logout does not clear the shared query cache. A later login in the same app lifetime can encounter cached data under the same keys. This is a code-level isolation risk, not a reported incident. I would scope protected queries to identity or tenant and clear or cancel them on session transitions, then test account switching with populated data.

Mutations make cache consistency explicit. Ticket creation invalidates ticket lists. Status updates patch the confirmed response into an existing detail cache, then invalidate list and detail queries. Message creation appends the server-confirmed response:

    onSuccess: (newMessage) => {
      queryClient.setQueryData<Message[]>(
        messageKeys.ticket(ticketId),
        (existing) => (existing ? [...existing, newMessage] : [newMessage]),
      );
    },

This is not an optimistic update: the write occurs after success. If the conversation was not cached, the code seeds it with only the new message. The hook does not invalidate ticket detail or lists. Whether those views need refresh depends on what sending changes. As more views depend on a mutation, I would document affected queries and define reconciliation for incomplete caches or concurrent writers. I would add optimistic behavior only when its temporary identity, rollback, deduplication, and reconciliation costs are justified.

All inspected feature APIs use one Axios instance. It sets the API base URL, JSON headers, a ten-second timeout, and a request interceptor that adds the stored Bearer token. The AI suggestion call overrides the timeout to sixty seconds. The response interceptor removes the token on 401 and redirects to /login, except for /auth/me bootstrap failures:

    if (error.response?.status === 401) {
      storage.removeToken();
      const requestUrl = error.config?.url ?? "";
      const isSessionBootstrapRequest = requestUrl.includes("/auth/me");
      if (!isSessionBootstrapRequest) {
        window.location.href = "/login";
      }
    }

That broad redirect also applies to a failed login request, while the login page has its own invalid-credentials message. I would assign session expiry and transport classification to an explicit session boundary, with feature-specific recovery messages. That boundary should not flatten every response into “try again”: invalid credentials, forbidden access, missing resources, offline failures, and server errors ask for different next steps. The API client can normalize transport details, while feature code still decides what recovery makes sense in context.

Typed response annotations do not validate payloads at runtime; runtime checks are a future option if contract drift warrants them. The localStorage token choice also needs to be evaluated against the deployment threat model rather than treated as proof of comprehensive security.

The ticket, message, and AI reply workflow

Ticket detail brings together three feature concerns: the ticket query, a message thread, and an AI suggestion. Server-owned ticket and message data stay in Query; the composer draft and coordination state stay local.

Current implementation: generating a suggestion is an explicit mutation with pending, error, empty, and success states. Regenerate calls the mutation again; retry resets its error first. “Use Reply” places suggestion text into the composer. It does not send it. The user can review, edit, and submit separately. The handoff is:

                  onUseReply={(content) => {
                    setComposerDraft(content);
                    setComposerKey((current) => current + 1);
                  }}

Incrementing the key remounts the composer with the supplied initial text. That also resets its local state, so it replaces any existing edits. I would make draft replacement an explicit interaction contract, including a confirmation when preserving unsent text matters.

On message submit, the composer validates and trims the draft, disables input while the request is pending, and clears the field only after success. On failure it keeps the text and shows an error. The returned message is appended to the query cache. The detail page’s messageRefreshToken name might imply a refetch, but the thread uses it only as a scroll-effect dependency. The current workflow is request/response plus local cache updates; no subscription or polling mechanism was found for remote conversation changes.

This example shows why state ownership and feature boundaries meet at the page: the page coordinates a draft handoff, the feature hooks own data operations, Query owns server data, and the shared client carries authentication. That is enough coordination for the current flow, but draft lifetime and cross-view freshness need explicit rules as collaboration grows.

Where the design would become fragile

Several limitations are useful signals for future design, not evidence of production failures:

• Account-independent keys and retained cache: protected records can remain cached across logout. Scope or clear that cache when identity changes.

• Sampled metrics: the dashboard requests page one with a limit of 100, derives counts from that array, and warns at 100 that results may be truncated. Those values are not a complete aggregate. I would use a server aggregate contract and a separate bounded recent-ticket query.

• No list controls: ticket types and API accept filters and pagination, but the screen calls useTickets() without parameters and exposes no pagination controls. I would make shareable filters and pages URL state when users need reload, sharing, or browser history.

• Loading and refresh semantics: list/detail/thread have loading, error, empty, and retry states. An error branch can replace content even if stale data exists. I would distinguish initial failure from background refresh failure and preserve usable content when appropriate.

• Feature coupling: message UI reuses ticket error wording, and dashboard derives from ticket hooks. I would keep transport errors shared while leaving domain messages with their owning feature.

A common design smell is duplicating server records in Redux or another global store while TanStack Query already owns them. Another is making AuthContext a general-purpose store for tickets, filters, and drafts. Neither is necessary here. Likewise, React-only permission checks, scattered HTTP clients, or component-only filters that users expect to bookmark are future risks to guard against, not current claims about every part of this app.

A mutation can succeed while one view remains stale even when another view updates correctly. Invalidating a list does not automatically define what happens to its detail page, dashboard aggregate, or sort order. The reverse mistake is invalidating everything and triggering needless network work. I would start by naming the views affected by the server operation, then choose a narrow cache patch, invalidation, or refetch for each. If a workflow has delayed server-side processing, the response to the initial mutation may not contain the final state; the client needs a refresh policy that matches that lifecycle.

Loading, error, and empty are not interchangeable placeholders. An empty list means the request succeeded and returned no records. A failed request means the interface does not know whether records exist. A background refresh can fail while previously fetched data is still useful. Treating those cases separately preserves context and makes retry behavior clearer. The current screens cover initial loading, error, empty, and content; retaining stale content through a failed background refresh is a possible evolution, not behavior I am claiming today.

Proposed architecture for a larger dashboard

I would keep the existing feature organization and sharpen its boundaries. This is proposed architecture, not the repository’s current tree:

src/
  app/       providers, router, shell
  features/  auth, tickets, messages, ai, dashboard
  shared/    api transport, UI primitives, config

App -> Router -> Shell -> Feature page/coordinator
                          |-> local interaction state
                          |-> feature hook -> Query -> API -> Backend
AuthProvider -> session identity and bootstrap
URL          -> ticket id and proposed list parameters

The import direction matters more than the folder names. Features should own their queries, keys, API functions, and domain UI. Shared code should not import ticket policy. A page or feature coordinator should make cross-feature orchestration visible. The URL should become the canonical owner of committed search, filters, and pagination when those values should survive reloads or be shared; an uncommitted search draft can remain local.

For larger systems, I would keep list browsing separate from dashboard aggregates, define cache scope around identity, and write down each mutation’s affected views. Those choices address actual pressure points in the reference app rather than introducing a state library or folder structure for appearance.

Performance, testing, and observability

Currently implemented: query caching and freshness defaults, parameterized keys, a bounded first-page dashboard request, component-local form state, and useMemo for dashboard metric calculation and recent-ticket slicing. The memoization is present; no measured speedup is established. Ticket rows and message arrays are mapped normally. Routes are eagerly imported; no route code splitting or list virtualization was found.

I would address performance in this order: avoid unnecessary requests and payloads; cache with deliberate freshness; bound lists through pagination; place state so edits do not update unrelated consumers; inspect rendering scope; then measure whether virtualization or route splitting is justified. For this app, the dashboard’s fixed 100-item request is a bound, but it is also the reason its derived counts are approximate. The ticket list itself has no controls to request a smaller page. Before tuning React renders, I would resolve the data contract and give users a way to navigate a bounded result set.

Memoization follows evidence of repeated expensive work. It cannot fix a wrong aggregate or an oversized response. Likewise, code splitting only helps if the delivered route bundle or initial load is a demonstrated cost, and virtualization only helps if a large rendered collection is the bottleneck. Each adds behavior and loading edges that need their own verification.

Current tests: the frontend uses Vitest, React Testing Library, and MSW. Test sources cover routes, permission-sensitive UI, form validation, query states, mutations, auth interceptors, AI draft use, and accessibility regressions. Some helpers use real auth while many use mocked identity. I reviewed the test sources and configuration, not a fresh test run or coverage report; configured thresholds are not measured coverage. No browser e2e suite was found in the inspected inventory, and the accessibility tests do not establish complete accessibility.

What I would add: exercise auth bootstrap failures and account switching with cached data; verify permission-sensitive actions, loading/error/empty states, query/mutation behavior, routing, and critical forms in browser journeys. I found no frontend telemetry integration in the inspected source. I would add sanitized error reporting, API failure context, performance monitoring, and user-impact signals while excluding tokens and message contents.

Decisions I would keep explicit

My practical rule is simple: give each value an owner, each mutation a consistency policy, each permission an authoritative server check, and each asynchronous boundary a recovery path. The reference frontend has the core pieces; making cache lifetimes, URL state, and interaction transitions explicit is how I would evolve it as the product grows.

Originally published on my engineering blog: https://blog.ramjwork.in/frontend/react-dashboard-system-design

In my AI Support Assistant, a new message triggers BullMQ analysis of the ticket conversation. The request waits for database writes and queue publication, then returns without waiting for the AI results.

But a retryable job can still run more than once, reload different context, race with another job, repeat provider work or overwrite newer results. The message can also be saved without its analysis job reaching Redis.

Examining the current implementation makes those boundaries concrete. The scenarios below are correctness risks exposed by the code, not production incidents; the proposed fixes are not implemented features.

The System This Came From

The first article described the broader React, Node.js, PostgreSQL, Redis and OpenAI architecture.

This article focuses on one workflow: a message is added to a support ticket, and background processing generates a summary, sentiment and priority. Those values are written back to the ticket. The worker also records an AIInteraction containing the conversation, summary response and summary token usage.

The queue is named ai-processing. Its job type is generate-ticket-summary, although the processor does more than summarize. It analyzes the whole ticket conversation, rather than just the message that triggered publication.

Why the AI Work Went to BullMQ

Saving a message and enriching a ticket have different completion requirements. The message is the user-authored record. AI metadata can arrive later.

The current boundary looks like this:

React client → Node.js API → PostgreSQL: Message + Ticket timestamp
                         → Redis/BullMQ: publish analysis job
                         → HTTP 201 after publication

Redis/BullMQ → separate worker → load ticket messages
                              → summary → sentiment → priority
                              → update Ticket → insert AIInteraction

Publication makes the job available to the worker. The worker may start before HTTP 201 is sent; the diagram shows two execution paths, not a guarantee that background processing begins after the response.

The important boundary is what the request awaits: persistence and publication, followed by a return to the caller. Summary, sentiment and priority belong to the worker's lifecycle.

The Actual Producer Flow

From backend/src/modules/messages/message.service.ts, lines 26–58. Authorization precedes this excerpt. The excerpt is otherwise complete; blank lines are condensed.

const message = await createMessageRepository({
  content: data.content,
  ticketId: data.ticketId,
  senderId: data.senderId,
});

await updateTicketRepository(data.ticketId, {
  updatedAt: new Date(),
});

await aiQueue.add(
  GENERATE_TICKET_SUMMARY_JOB,
  {
    ticketId: data.ticketId,
    messageId: message.id,
  },
  {
    attempts: 3,
    backoff: {
      type: "exponential",
      delay: 5000,
    },
    removeOnComplete: true,
    removeOnFail: false,
  },
);

return message;

The repository helpers execute prisma.message.create and prisma.ticket.update. These are separate writes, followed by publication to Redis. There is no encompassing transaction or outbox in this flow.

The controller awaits this service before returning HTTP 201. Consequently, a message can already exist even if the service does not reach its successful return. Queue publication is part of request completion; AI processing is not.

The payload includes messageId, but the worker's processing logic only consumes ticketId. The message ID currently provides neither a processing boundary nor an idempotency key.

What the Worker Actually Does

The worker dispatches generate-ticket-summary to processTicketSummaryJob using only the ticket ID. Its configuration in backend/src/queues/ai.worker.ts, lines 71–75, is:

{
  connection: redis as any,
  concurrency: 5,
},

This is the complete options object from the worker constructor, with blank lines condensed.

Five jobs can run concurrently within this worker instance, including jobs for the same ticket. This is a local worker limit, not a global or per-ticket limit. See BullMQ’s worker concurrency guide.

The processor loads messages with where: { ticketId }, includes sender role and name, and sorts by createdAt: "asc". It returns early when there are no messages. Otherwise it formats the conversation and executes this sequence from lines 113–127:

const aiResult = await generateTicketSummary(
  {
    conversation,
  },
  aiContext,
);

const sentimentResult = await generateSentiment(
  {
    conversation,
  },
  aiContext,
);

const priorityResult = await detectTicketPriority(conversation, aiContext);

These operations are sequential within one job. Different jobs can still overlap. The service routes generation through an OpenAI-primary orchestrator with optional Gemini fallback for eligible failures, so three logical operations do not necessarily mean exactly three external HTTP requests.

After sentiment and priority validation, lines 133–155 perform two separate writes:

await prisma.ticket.update({
  where: {
    id: ticketId,
  },
  data: {
    aiSummary: aiResult.summary,
    sentiment,
    priority,
  },
});

await createAIInteraction({
  ticketId,
  prompt: conversation,
  response: aiResult.summary || "",
  tokensUsed: aiResult.tokensUsed,
});

Blank lines are condensed. createAIInteraction is a plain Prisma insert. There is no job identity or conversation version attached to that record, and no conditional version check on the ticket update.

The worker runs through a separate entry point in backend/src/worker.ts. That separates its execution lifecycle from HTTP handling; it does not add coordination between jobs for one ticket.

Retries Solve Failure Recovery, Not Correctness

The producer configures three total attempts, including the initial execution, with exponential backoff and a five-second base. For ordinary thrown-error retries, that gives nominal delays of five and ten seconds before the remaining attempts; scheduling can add waiting time. See BullMQ's retry documentation.

Completed jobs are removed. Failed jobs are retained. Those choices affect recovery and diagnosis, but they do not make processing idempotent.

Retry asks, “Should I try this work again after failure?” Idempotency asks, “If I perform it again, will the resulting state remain correct?” Deduplication asks, “Should equivalent work be admitted or executed again at all?”

Here, retries restart a processor that calls providers and performs database writes. The retry configuration supplies no rule for deciding whether those effects have already happened.

Failure Mode 1: The Database Commits but the Queue Does Not

Consider the producer's actual order:

1. The message insert succeeds.
2. The ticket timestamp update succeeds.
3. Publication rejects, or the process exits before publication completes.

The database now contains the conversation change without assured corresponding queue work. Retrying a worker cannot recover a job that was never published.

A publication error can also leave an ambiguous outcome: Redis might have accepted the job before the caller lost its acknowledgement. Recovery must handle both missing work and repeated publication.

The earlier boundary also matters: if the ticket update fails after message creation, the message remains persisted and publication is never reached. Wrapping those two database writes in a transaction would address that database-only partial state. It would not atomically commit a Redis job with PostgreSQL data.

A proposed transactional outbox changes where publication intent becomes durable:

BEFORE — CURRENT
Message insert → Ticket update → Redis publication
     database writes complete       can fail separately

IMPROVED — PROPOSED
PostgreSQL transaction:
  Message insert + Ticket update + Outbox event
                         ↓ committed publication intent
Outbox dispatcher → Redis/BullMQ → worker
       ↓
mark event published after successful queue publication

The dispatcher retries unpublished events. If it publishes and crashes before marking the event, it may publish again. An outbox therefore needs stable event identity and duplicate-safe consumption; it does not confer exactly-once execution.

This adds a table, dispatcher lifecycle, backlog monitoring and retention policy. For optional enrichment in an early application, explicit reconciliation may be an interim choice. If every accepted message must eventually be analyzed, I would prioritize an outbox regardless of traffic volume. Reliability requirements, rather than scale alone, determine when it is needed.

Failure Mode 2: Retrying AI Work Is Not Automatically Idempotent

Suppose summary generation succeeds and sentiment generation fails with an error that escapes the provider layer. BullMQ can retry the processor. It starts again by loading messages and generating the summary. There is no checkpoint that reuses the previous summary.

Now move the failure later. Summary, sentiment and priority succeed; the ticket update commits; the interaction insert fails. The ticket already contains AI metadata, but the job has failed. A retry repeats the AI sequence and attempts both database writes again.

The resulting values need not match the previous output. More messages may also have arrived before the retry reloads the conversation. The same job payload therefore does not necessarily identify the same input snapshot.

A duplicate execution that reaches the insert can append another AIInteraction: its schema uses a generated UUID and has no unique analysis key. Interruption after application writes but before queue completion is recorded creates another window for repeated effects. The relevant effects here are provider requests, ticket metadata writes and interaction records.

Deterministic job identity helps at publication

A proposed identity such as ticket-analysis-<messageId> could suppress repeated publication for the same saved message while that queue job exists. It would not suppress jobs triggered by two different messages, nor deduplicate message creation if a repeated HTTP request creates a new message ID.

BullMQ's job ID documentation explains that an existing custom ID prevents another job with that ID from being added. Once the job is removed, the ID no longer protects against duplicates. That is directly relevant to this application's removeOnComplete: true setting.

Durable idempotency belongs at the application effect

For this workflow, I would define a logical analysis key from ticket identity, conversation revision and analysis/prompt version. A durable record with a unique constraint could track whether that analysis has already been applied.

The ticket update, interaction insert and successful analysis marker should commit together, with concurrent duplicate attempts resolved by database constraints and conditional writes. A separate initial “already done?” read is insufficient because two workers can both pass it.

That would protect database effects. Provider requests made before commit could still repeat. Reusing stored generation results would require checkpointing and invalidation rules; I would start with atomic result persistence and durable identity.

Failure Mode 3: Ordering Is a Business Constraint

Two messages arrive quickly on ticket T:

1. Message A is saved and job A starts. It reads the conversation containing A.
2. Message B is saved and job B starts in another available worker slot. It reads A and B.
3. Job B finishes first and writes metadata based on A and B.
4. Job A finishes later and overwrites that metadata using its older context.

The current ticket update matches only id: ticketId. Nothing prevents step four. This is a possible stale, last-writer-wins result visible from the architecture.

Both jobs could also start after B exists, read overlapping or identical context, and perform redundant analysis. Because messageId is unused, neither job is restricted to the conversation as it stood when its triggering message was saved.

Sorting messages inside each job does not order jobs or their writes. The timestamp sort also has no explicit tie-breaker for equal timestamps.

Global throughput and per-ticket correctness are separate constraints. Lowering one worker's concurrency to one would reduce overlap there, but also serialize unrelated tickets and would not establish a cross-process ordering policy.

Idempotency, Deduplication and Ordering Are Different

Only retries and worker concurrency are configured in the current path. The other examples describe proposed behavior. A version check can reject stale results without executing every job in strict order; serialization still needs a policy for retries and earlier failures.

A Better Per-Ticket Processing Model

The following is a proposed model, not current code. For summary, sentiment and priority, the business goal is usually a current conversation view. It may not require publishing every intermediate analysis.

Messages A, B, C → atomically advance ticket conversation revision
                                   ↓
                       record latest requested revision
                                   ↓
                 coalesce pending work for this ticket
                                   ↓
                 one active analysis per ticket, if needed
                                   ↓
                    read consistent snapshot at revision R
                                   ↓
                            generate AI results
                                   ↓
                  atomic apply only if revision is still R
                          ↙                      ↘
                stale: discard              current: commit
                    ↓                    results + analysis record
         ensure latest revision remains scheduled

Version checks are the first correctness protection I would add. A dedicated conversation revision should advance atomically with message persistence. The worker must read the revision and messages as a consistent snapshot, then conditionally apply results in a short database transaction. A separate check followed by an unconditional update leaves a race.

I would avoid using Ticket.updatedAt as the conversation revision. Prisma marks it @updatedAt, so AI writes and unrelated ticket edits also change it. A dedicated revision makes the input contract explicit. The tradeoff is schema and transaction work; discarded stale analyses still consume processing. This protection is useful now because the current concurrency already permits stale writes.

Coalescing can reduce unnecessary work. Several pending triggers can represent one request to analyze the latest conversation. A short debounce period trades freshness for fewer intermediate analyses. BullMQ offers deduplication modes, but their lifetime semantics must match the application.

In particular, simply suppressing every new job while one analysis is active can miss updates arriving after that analysis loaded its messages. The design must durably track the latest requested revision and arrange another pass when needed. Checking once at the end without an atomic handoff can still lose a concurrent update. Coalescing is a pragmatic next step when message bursts cause redundant work; it is not a substitute for version checks.

Per-ticket serialization can limit overlap. A coordinated lease or partitioned processing scheme can allow different tickets to progress concurrently while restricting one ticket's active analysis. An in-memory mutex covers only one process. Distributed leases introduce expiry, renewal and crash-recovery concerns; conditional version checks remain valuable when a lease expires while work is still running.

If a future job must act on every message in business order, it needs explicit sequence tracking and a policy for earlier failures. Coalescing intermediate analyses would no longer satisfy that requirement.

What I Would Change First

These are recommendations for this application, not features already implemented.

1. Define analysis identity and protect freshness together. Introduce a conversation revision, conditional result application and an atomic transaction for ticket metadata, interaction and an analysis marker. Then use deterministic publication identity for the chosen unit of work. This addresses correctness exposed by today's concurrency; it costs a schema change and careful transaction design.
2. Coalesce pending ticket analysis where the product permits it. Treat the job as “refresh this ticket” rather than “produce every intermediate result,” while preserving a durable follow-up for changes during active processing. This costs scheduling complexity and may delay freshness slightly. It becomes more useful when bursts create redundant work. Add coordinated per-ticket serialization if overlap remains significant; version protection comes first.
3. Close the database-to-queue gap when eventual analysis is required. Add an outbox and replay-safe dispatcher. Also review producer connection policy: the shared Redis module sets maxRetriesPerRequest: null, and the message service has no explicit publication deadline. BullMQ’s connection guidance distinguishes worker recovery from bounded waiting in HTTP producers. The operational cost is real, but the need depends on the reliability contract, not a hypothetical high-traffic milestone.
4. Build recovery on the visibility already present. The worker logs receipt, completion, failures, ticket/job IDs and duration. Before using the attempt fields for alerts, I would verify their meaning at receipt and failure events. Add exhausted-attempt alerts, queue age/backlog visibility, stale-result counters and revision correlation. These are useful now; a larger telemetry platform can wait.
5. Add a deliberate replay policy. Retained failed jobs are a starting point, not an implemented dead-letter workflow. An operator should distinguish transient failures from invalid input, replay after repair, and know whether replay means the original snapshot or latest conversation. Controlled replay tooling and retention add maintenance work. A separate dead-letter queue is optional until volume or operational ownership warrants it.

I would evaluate these changes through duplicate work, result freshness and publication failures. Infrastructure changes should follow a demonstrated constraint.

What I Would Not Add Yet

I would not introduce Kafka, Kubernetes or decompose the application into microservices solely because it has a queue.

The concrete concerns are durable publication intent, safe repeated writes and valid application of conversation-derived results. They can be addressed within PostgreSQL, Redis, BullMQ and the existing API/worker boundary.

More infrastructure may become appropriate under specific throughput, ownership or deployment constraints. It does not remove the need to define what makes an analysis current or safe to repeat.

Why AI Workloads Make This More Visible

In this worker, three sequential generation operations separate the initial conversation read from the final ticket update. While those external requests are in flight, another message can arrive and another job can complete. The queue can function normally while the result becomes obsolete.

Provider calls can be relatively slow, and successful generation consumes usage billed under the provider’s terms; OpenAI documents token-based API pricing. Repeating a completed summary because sentiment failed can therefore repeat meaningful work, even when no database row has yet changed. This is a reason to control repetition, not a measured cost or latency claim about this application.

Generated text can also differ between attempts. Overwriting aiSummary with a second output is not automatically idempotent just because both writes target the same row. Meanwhile, this processor reloads messages on every attempt, so a retry can change both its input and its output.

For this workload, the useful contract is: which conversation revision does this analysis describe, and when may it take effect? The queue schedules execution. The application must answer that question.

Final Takeaway

BullMQ gives this application a clear boundary between message creation and background AI enrichment. Correctness still needs an application-level design: durable publication intent, duplicate-safe effects and protection against stale conversation results.

Retries make another attempt possible. Idempotency and ordering rules determine whether that attempt is safe to apply.

Originally part of the engineering work behind my AI Support Assistant architecture.

Originally published on my engineering blog: https://blog.ramjwork.in/ai-engineering/redis-bullmq-ai-background-jobs

Adding AI wasn’t the difficult part. Deciding where AI belongs in the application architecture was.

Adding an LLM API to an application is relatively straightforward.

The harder questions begin after the first API call works.

Should AI run inside the user’s HTTP request? What happens when the provider is slow? Which AI operations should be asynchronous? What belongs in React state versus server state? Should an AI-generated support reply be sent automatically? What happens when a background job retries after partially completing?

I ran into these questions while building an AI-powered customer support application with React, TypeScript, Node.js, PostgreSQL, Redis, BullMQ and OpenAI.

The interesting part of the project wasn’t the prompt.

It was deciding where AI should—and should not—sit inside the system.

This article walks through that architecture, shows selected code from the actual implementation, and discusses several things I would change before scaling the design further.

What the Application Does

The application revolves around support tickets and conversations.

It has three roles:

• Customers create tickets, read their own tickets and add messages.
• Agents work with assigned tickets, update their status and request AI-generated reply suggestions.
• Admins have broader ticket access and assignment capabilities.

AI assists the workflow in two different ways.

First, when a new message is added, background processing analyzes the ticket conversation to generate:

• a ticket summary,
• sentiment,
• priority.

Second, an agent or admin can explicitly request an AI-generated reply suggestion.

Those two AI workloads look similar at first—they both call an LLM—but they have very different execution requirements.

That distinction shaped much of the architecture.

High-Level Architecture

At a high level, the system looks like this:

                    ┌─────────────────────────┐
                    │       React Client      │
                    │                         │
                    │ Auth / Tickets /        │
                    │ Messages / AI Replies   │
                    └────────────┬────────────┘
                                 │
                              REST API
                                 │
                    ┌────────────▼────────────┐
                    │     Node.js / Express   │
                    │                         │
                    │ Auth → Controller →     │
                    │ Service → Repository    │
                    └───────┬─────────┬───────┘
                            │         │
                            │         │ enqueue
                            │         ▼
                    ┌───────▼───┐  ┌──────────────┐
                    │PostgreSQL │  │ Redis/BullMQ │
                    └───────────┘  └──────┬───────┘
                                         │
                                         ▼
                                  ┌─────────────┐
                                  │  AI Worker  │
                                  │             │
                                  │ Summary     │
                                  │ Sentiment   │
                                  │ Priority    │
                                  └──────┬──────┘
                                         │
                                    LLM provider

The application is deliberately not split into many network services.

The API is a modular monolith, while AI background execution runs in a separate worker process.

That gives me an important boundary without introducing a distributed-service architecture prematurely:

HTTP request handling and background AI processing have independent execution lifecycles.

Frontend State: Don’t Put Everything in One Store

One frontend decision was to separate state based on who owns it.

I use three broad categories:

• authentication/session state → React Context,
• remote server state → TanStack Query,
• transient UI state → local component state.

For example, tickets are server-owned resources, so their fetching and cache lifecycle belong to TanStack Query:

export function useTickets(params?: TicketListParams) {
  return useQuery({
    queryKey: ticketKeys.list(params),
    queryFn: () => getTickets(params),
  });
}

export function useTicket(ticketId: string) {
  return useQuery({
    queryKey: ticketKeys.detail(ticketId),
    queryFn: () => getTicketById(ticketId),
    enabled: Boolean(ticketId),
  });
}

export function useCreateTicket() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (payload: CreateTicketRequest) => createTicket(payload),

    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ticketKeys.lists() });
    },
  });
}

The important part here isn’t the library.

It’s the ownership model.

A ticket fetched from the API is not fundamentally client state. The server remains authoritative.

TanStack Query handles fetching, caching and invalidation, while component-local state handles things such as editable drafts and temporary UI interactions.

This prevents a common React architecture problem: turning one global store into a mirror of the backend.

The Backend Is a Modular Monolith

The backend follows a layered flow that is roughly:

Route
  ↓
Authentication / Authorization / Validation
  ↓
Controller
  ↓
Service
  ↓
Repository
  ↓
Prisma
  ↓
PostgreSQL

This gives features such as tickets and messages clear boundaries without requiring each feature to become an independent service.

The service layer owns application workflows.

Repositories isolate most persistence operations.

Controllers remain focused primarily on translating HTTP requests and responses.

AI is a partial exception because some worker-side operations interact more directly with Prisma, but the overall HTTP architecture follows this separation.

For the current scope, I prefer this to creating multiple microservices.

A service boundary should solve an actual deployment, ownership or scaling problem—not exist simply because the system has multiple features.

Why I Moved AI Analysis Out of the Request Path

Consider what happens when a customer adds a message.

The important user-facing operation is:

Persist my message successfully.

Summary, sentiment and priority enrichment are useful, but the user should not have to wait for several LLM operations to complete before the message request can finish.

The service therefore persists the message and publishes a BullMQ job:

export const createMessageService = async (data: CreateMessageInput) => {
  await getAuthorizedTicketService(data.ticketId, data.accessContext);

  const message = await createMessageRepository({
    content: data.content,
    ticketId: data.ticketId,
    senderId: data.senderId,
  });

  await updateTicketRepository(data.ticketId, {
    updatedAt: new Date(),
  });

  await aiQueue.add(
    GENERATE_TICKET_SUMMARY_JOB,
    {
      ticketId: data.ticketId,
      messageId: message.id,
    },
    {
      attempts: 3,
      backoff: {
        type: "exponential",
        delay: 5000,
      },
      removeOnComplete: true,
      removeOnFail: false,
    },
  );

  return message;
};

There is an important architectural detail here.

The HTTP request does wait for queue publication, but it does not wait for the AI analysis itself.

Conceptually:

POST message
     │
     ▼
Authorize access
     │
     ▼
Persist message
     │
     ▼
Update ticket timestamp
     │
     ▼
Publish BullMQ job
     │
     ├──────────────► HTTP response
     │
     ▼
Background worker
     │
     ▼
AI processing

That removes LLM execution time from the main request path while still ensuring the API knows whether it successfully handed work to the queue.

It also allows the worker lifecycle to be operated separately from the HTTP server.

What the Background Worker Actually Does

BullMQ uses Redis as the queue infrastructure.

A separate worker consumes AI-processing jobs:

export const aiWorker = new Worker(
  AI_QUEUE,

  async (job) => {
    const startedAt = Date.now();
    jobStartTimes.set(String(job.id), startedAt);

    const ticketId =
      typeof job.data?.ticketId === "string" ? job.data.ticketId : undefined;

    workerLogger.info(
      {
        event: "ai_job_received",
        jobId: job.id,
        jobName: job.name,
        ticketId,
        attempt: job.attemptsMade + 1,
      },
      "Job received",
    );

    switch (job.name) {
      case GENERATE_TICKET_SUMMARY_JOB:
        await processTicketSummaryJob(ticketId ?? job.data.ticketId);
        break;

      default:
        workerLogger.warn(
          {
            event: "ai_job_unknown",
            jobId: job.id,
            jobName: job.name,
            ticketId,
          },
          "Unknown job",
        );
    }
  },

  {
    connection: redis as any,
    concurrency: 5,
  },
);

Inside the ticket-processing workflow, messages are loaded in conversation order and transformed into the conversation passed to the AI layer.

The relevant part of the processing pipeline is:

const conversation = formatConversation(messages);

const aiResult = await generateTicketSummary(
  {
    conversation,
  },
  aiContext,
);

const sentimentResult = await generateSentiment(
  {
    conversation,
  },
  aiContext,
);

const priorityResult = await detectTicketPriority(
  conversation,
  aiContext,
);

const sentiment = validateSentiment(
  sentimentResult.sentiment || "",
) as any;

const priority = validatePriority(
  priorityResult.priority || "",
) as any;

Summary, sentiment and priority are currently generated sequentially inside a job.

The normalized results are then used to update ticket-level AI fields, and an AI interaction record is created for the summary workflow.

This design gives the application retryable asynchronous execution without coupling LLM latency directly to message creation.

But queues introduce their own problems.

I’ll return to those shortly.

Not Every AI Operation Belongs in a Queue

Once background processing existed, it would have been easy to conclude:

AI is slow, therefore every AI operation should be queued.

I don’t think that is the right abstraction.

The correct execution model depends on what the user is doing.

Ticket analysis is enrichment. It can happen asynchronously.

An agent clicking Generate Reply, however, is explicitly waiting for an answer.

For that workflow, the backend generates the suggestion synchronously:

const conversation = formatConversation(messages);

const aiResult = await generateReplySuggestion(conversation, {
  ticketId,
  requestId: typeof req.id === "string" ? req.id : undefined,
});

res
  .status(200)
  .json(new ApiResponse("Reply suggestion generated", aiResult));

The important distinction is:

Background analysis
Message → Queue → Worker → AI → Ticket metadata

Interactive assistance
Agent → Request suggestion → AI → Suggested text → Agent

The second flow doesn’t automatically create or send a support message.

That is intentional.

Human-in-the-Loop AI

A generated support reply can be wrong, incomplete or inappropriate for the context.

So the system treats AI output as a suggestion, not an autonomous action.

On the frontend:

<ReplySuggestion
  ticketId={data.id}
  onUseReply={(content) => {
    setComposerDraft(content);
    setComposerKey((current) => current + 1);
  }}
/>

<MessageComposer
  key={composerKey}
  ticketId={data.id}
  initialContent={composerDraft}
  onMessageSent={() =>
    setMessageRefreshToken((current) => current + 1)
  }
/>

When the user selects Use Reply, the suggestion is moved into the normal message composer.

The agent can then:

Generate
   ↓
Review
   ↓
Edit
   ↓
Send

The AI does not own the final action.

That boundary matters more to me than simply adding another confirmation dialog.

The application architecture itself separates generation from execution.

This is a pattern I would reuse in many AI-assisted workflows where the output affects another person or an important business process.

AI Provider Logic Belongs Behind an Application Boundary

The application currently uses an OpenAI-backed adapter for operations such as:

• summarization,
• sentiment analysis,
• priority detection,
• reply suggestions.

There is also provider orchestration that can use Gemini as a fallback for selected classes of provider, quota, rate-limit, network or timeout failures.

I don’t want ticket or message business logic to know the details of every provider.

Conceptually:

Business workflow
       │
       ▼
AI operation
       │
       ▼
Provider orchestration
       │
       ├── OpenAI
       │
       └── Gemini fallback

This boundary becomes useful even if the application never changes providers.

It gives one place to reason about:

• prompts,
• provider failures,
• normalization,
• fallback rules,
• model configuration.

Provider abstraction does not mean every model is interchangeable.

Different models behave differently.

The goal is simply to stop provider-specific concerns from leaking through the rest of the application.

Authentication Is Not Authorization

The application uses JWT authentication, but authentication alone does not answer:

Is this user allowed to access this particular ticket?

A valid token identifies the user and role.

Resource authorization still has to be enforced.

For example:

• customers should only access their own tickets,
• agents operate on tickets available to their role and assignment rules,
• admins have broader access.

The frontend also hides or exposes functionality according to role, but that is a UX decision—not a security boundary.

The backend remains authoritative.

This distinction is especially important in React applications because hiding a button is easy to mistake for enforcing permission.

It isn’t.

Redis Has More Than One Responsibility

Redis is not used only because BullMQ needs it.

In this project it also supports:

• short-lived ticket caching,
• distributed rate-limit counters.

That makes Redis shared infrastructure serving different concerns:

Redis
├── BullMQ queue infrastructure
├── ticket cache
└── rate-limit counters

Those responsibilities should still remain conceptually separate even if they use the same underlying technology.

A queue is not a cache.

A cache is not a source of truth.

The database remains the authoritative store for ticket and conversation data.

What the Architecture Gets Right

There are several boundaries in this design that I would keep.

1. User-facing writes are separated from AI enrichment

Message creation does not wait for summary, sentiment and priority generation.

2. Interactive AI and background AI use different execution models

The system chooses between synchronous and asynchronous execution based on the user workflow rather than treating all AI calls identically.

3. Server state remains server state

TanStack Query manages API-backed ticket state rather than copying everything into a global client store.

4. AI suggestions do not automatically become actions

Generated replies remain editable suggestions.

5. HTTP and worker lifecycles are separate

The API server and AI worker can fail, restart and evolve independently at the process level.

But none of those decisions makes the architecture finished.

Several weaknesses become more important as concurrency and operational requirements increase.

What I Would Change Before Scaling

This is the part of the architecture I find most useful to examine.

Queues solve one category of problem while creating others.

1. Fix the Database-to-Queue Consistency Gap

Look again at message creation:

Write message to PostgreSQL
        ↓
Update ticket
        ↓
Publish BullMQ job

These are separate operations.

Imagine:

1. PostgreSQL successfully saves the message.
2. Redis becomes unavailable before aiQueue.add() succeeds.

The application now has committed business data without the corresponding background event.

Retries do not solve this consistency problem.

A stronger design would introduce a transactional outbox.

Conceptually:

             PostgreSQL transaction
        ┌────────────────────────────┐
        │ Save message               │
        │ Save outbox event          │
        └──────────────┬─────────────┘
                       │ commit
                       ▼
                Outbox publisher
                       │
                       ▼
                   BullMQ
                       │
                       ▼
                    Worker

The message and the intent to perform AI processing would be committed atomically in PostgreSQL.

A separate publisher could then reliably move pending outbox events into BullMQ.

That doesn’t make the entire system exactly-once.

It closes a specific and important consistency gap.

2. Retries Need Idempotency

The queue currently configures multiple attempts with exponential backoff.

That improves recoverability from transient failures.

But:

retryable does not automatically mean safe to retry.

Suppose a job:

1. calls the AI provider,
2. updates the ticket,
3. writes an AI interaction,
4. fails somewhere around those operations,
5. retries.

Without explicit idempotency, repeated attempts can repeat side effects.

A stronger implementation would give each logical processing operation a stable identity and make persisted effects safe to replay.

Possible approaches include:

• deterministic job IDs,
• processing-version records,
• unique database constraints,
• upsert semantics,
• explicit processed-event records.

The exact mechanism depends on the workflow.

The architectural requirement is simpler:

A retry should not accidentally turn one logical operation into multiple business effects.

3. Protect Against Same-Ticket Concurrency

The worker has concurrency greater than one.

That’s useful for processing unrelated tickets.

But it also means two jobs for the same ticket can overlap.

Consider:

Ticket conversation V1
        │
        └── Job A starts

New message arrives
        │
Ticket conversation V2
        │
        └── Job B starts

Job B finishes first → stores V2 analysis
Job A finishes later → stores older V1 analysis

The final ticket can now contain stale AI metadata.

This is not solved by generic worker concurrency configuration alone.

Before scaling the workflow, I would introduce some combination of:

• per-ticket serialization,
• conversation version numbers,
• compare-before-write logic,
• coalescing pending analysis jobs,
• stale-result rejection.

The important principle is that global concurrency and entity-level ordering are different problems.

4. Give the UI an Explicit AI-Result Delivery Mechanism

Background processing creates another question:

How does the browser learn that AI analysis has finished?

The current architecture does not implement a dedicated real-time result-delivery channel.

At larger scale or with a richer UI, I would make that explicit.

Depending on the product requirements:

Simplest
Polling

        ↓

More event-driven
Server-Sent Events

        ↓

Bidirectional realtime needs
WebSockets

I would not automatically choose WebSockets.

If the browser only needs server-to-client status updates, SSE may be enough.

Architecture should follow the interaction requirement, not the popularity of the technology.

5. Tighten Cache Freshness Rules

Caching ticket data can reduce repeated reads, but mutable support conversations create invalidation challenges.

Every path that changes data relevant to a cached ticket needs a clear freshness strategy.

Before relying more heavily on caching, I would explicitly document:

• what is cached,
• the cache key,
• TTL,
• which writes invalidate it,
• whether stale reads are acceptable,
• what happens when invalidation fails.

A short TTL is useful, but TTL alone isn’t a complete consistency model.

6. Improve the AI Context and Evaluation Layer

The current AI pipeline is intentionally straightforward.

There are several improvements I would investigate before treating AI behavior as a mature subsystem:

• explicit structured outputs,
• conversation-size/token management,
• better context construction,
• prompt/model version tracking,
• evaluation datasets,
• regression testing for AI behavior,
• provider health telemetry,
• clearer usage accounting,
• privacy and retention policies for model inputs and outputs.

I would add these based on actual product requirements rather than building an elaborate AI platform prematurely.

The important shift is from:

Does the model return something?

to:

Can I measure whether this AI behavior remains useful and reliable as the application changes?

What I Would Not Add Yet

Scaling discussions can easily turn into architecture shopping lists.

I would not automatically add:

• Kafka,
• Kubernetes,
• multiple microservices,
• vector databases,
• WebSockets,
• event sourcing,
• multiple caches.

None of those technologies is inherently an upgrade.

For this system, I would first strengthen the guarantees around the architecture that already exists:

DB/queue consistency
        ↓
Idempotent processing
        ↓
Per-ticket ordering/versioning
        ↓
Observable job state
        ↓
AI evaluation
        ↓
Scale infrastructure when evidence requires it

Complexity should be purchased with a requirement.

The Most Important Lesson: AI Is a Workload, Not the Architecture

It is tempting to describe this application as an OpenAI integration.

That misses most of the engineering.

The LLM is one dependency inside a larger system.

The architecture still has to answer ordinary software-engineering questions:

• Who owns state?
• Which operations block the user?
• What should happen asynchronously?
• Where is authorization enforced?
• What happens after partial failure?
• Are retries safe?
• Can concurrent work overwrite newer state?
• How does the UI learn that background work finished?
• Where does human approval belong?

Those questions existed before LLMs.

AI simply makes several of them more visible because model calls are external, comparatively slow, probabilistic and failure-prone.

Final Architecture

The current design can be summarized as:

                           React + TypeScript
                                  │
                 ┌────────────────┼────────────────┐
                 │                │                │
            Auth Context     TanStack Query    Local UI State
                 │                │                │
                 └────────────────┼────────────────┘
                                  │
                                  ▼
                           Express REST API
                                  │
                    Auth / AuthZ / Validation
                                  │
                                  ▼
                       Application Services
                         │               │
                         │               │
                         ▼               ▼
                    PostgreSQL      Redis / BullMQ
                                         │
                                         ▼
                                     AI Worker
                                         │
                             ┌───────────┼───────────┐
                             │           │           │
                          Summary    Sentiment    Priority
                             │           │           │
                             └───────────┼───────────┘
                                         │
                                    AI Providers


Interactive reply path:

Agent → API → AI reply suggestion → editable composer → human sends

It is intentionally simpler than a large distributed system.

And it has known limitations.

I consider both of those facts healthy.

Good architecture is not about pretending the current system can handle every future requirement.

It is about knowing which guarantees the system currently provides, which ones it doesn’t, and where the next architectural pressure points will appear.

Closing

Building this project changed how I think about adding AI to existing applications.

I wouldn’t start by asking:

Where can I call the LLM?

I would start with:

What role should AI have in this workflow?

Then decide:

• synchronous or asynchronous,
• advisory or autonomous,
• user-facing or background,
• retryable or idempotent,
• cached or authoritative,
• human-reviewed or automatically executed.

Once those boundaries are clear, choosing the API is usually the easier part.

In the next article in this architecture series, I’ll go deeper into BullMQ background jobs for AI workloads—especially retries, idempotency and ordering, because adding a queue is only the beginning of making background processing reliable.

About the author

I’m Ram Ji Tripathi, a senior frontend-focused full-stack engineer working across React, TypeScript, Node.js and AI-enabled applications.

I write about frontend architecture, backend systems, AI engineering, system design and the engineering decisions behind building real software.

More engineering notes and projects are available on my portfolio.

Originally published on my engineering blog: https://blog.ramjwork.in/ai-engineering/ai-customer-support-architecture