DEV Community: CometChat

Ordering, Receipts and Reconnects: The Chat Client Problems That Only Appear on a Bad Network

Vishal Singh — Thu, 08 Oct 2026 07:25:31 +0000

Ordering, Receipts and Reconnects: The Chat Client Problems That Only Appear on a Bad Network

A chat feature demoed on office wifi is a solved problem. The same feature on a train is a different piece of software. Messages arrive out of order, the same message arrives twice, a send appears to fail and then succeeds, and the unread count disagrees with the thread.

Working on real-time messaging at CometChat, the failures I see reported are rarely ""the socket did not connect"". They are subtler: a message that sits in a sending state forever, an ordering that differs between two devices, a duplicate after a tunnel. All four have the same root cause - the client trusted something it should not have.

Here are the four assumptions worth removing from your chat client.

1. Do not order by client timestamp

The obvious sort key is the sender's clock, and it is wrong. Device clocks drift, users travel across time zones, and a phone that has been asleep can be several seconds off. Sorting by Date.now() at the sender produces a thread that reads differently on different devices.

Order by a value the server assigns. A monotonically increasing per-conversation sequence number is the most useful shape, because it gives you three things at once:

a total order that every client agrees on
gap detection - if you hold 41 and 43, you know 42 exists and you are missing it
a cursor for pagination that does not break when two messages share a millisecond

Keep the sender's timestamp, and display it. Just do not sort by it. And when you render an optimistic message that has no sequence number yet, pin it to the end of the list rather than trying to guess its position.

2. Every send needs a client-generated identifier

An optimistic UI shows the message immediately. Then the network does something ambiguous: the request times out, or the socket closes before the acknowledgement arrives. The client does not know whether the server accepted it.

If the client retries and the server has no way to recognise the retry, the user has posted twice. This is the single most common duplicate-message bug, and the fix is small: generate an identifier on the client before sending, send it with the message, and have the server treat a repeat of that identifier as the same message.

const clientId = crypto.randomUUID();

// state: queued -> sent -> delivered | failed
await send({ clientId, conversationId, text });

The acknowledgement returns the server identifier and sequence number; the client reconciles by clientId and replaces the optimistic entry in place. Two properties follow, and both matter:

retrying is safe, so you can retry automatically
the same message arriving over the real-time channel and in the acknowledgement collapses into one row, because both carry the same client identifier

Keep the outbox durable. If the app is killed with three queued messages, they should still be there on relaunch, in order, with their state visible. A message that silently disappears is worse than one marked failed.

3. Reconnection is a sync, not a resubscribe

The instinct after a dropped socket is to reconnect and carry on listening. That leaves a hole: everything sent while you were away.

Reconnection needs three steps, in this order.

Step	Action
1	Reconnect the transport with jittered exponential backoff
2	Fetch what was missed, per conversation, from the last sequence number you hold
3	Only then apply live events, buffering anything that arrives during step 2

Getting this order wrong produces the classic artefact: live messages appear, then older messages arrive and shuffle in above them, and the list jumps under the user's thumb. Buffer live events during the catch-up fetch, then apply the buffer, deduplicating by identifier.

Backoff needs jitter for a reason that only shows up at scale. If a regional network blip disconnects a large number of clients at once, unjittered backoff reconnects them all in the same instant, and your infrastructure receives the thundering herd twice - once for the sockets and once for the catch-up queries.

Also treat ""the socket is open"" as insufficient evidence of health. Captive portals and dead middleboxes hold connections open that carry nothing. An application-level heartbeat with a response deadline is what actually tells you the connection works.

4. Receipts and presence are aggregate signals, not events

Delivery receipts, read receipts, and typing indicators are, per message, low-value and high-volume. In a busy group they can easily exceed the message traffic itself.

Treat them differently from messages:

Read state as a watermark. Store ""user X has read up to sequence 84"" rather than a receipt per message. One value per participant per conversation replaces hundreds of rows, and the unread count becomes arithmetic instead of a query.
Typing as a short-lived signal. Send a start on first keystroke, throttle repeats, and let the receiver expire it after a few seconds rather than relying on a stop event that a dropped connection will eat.
Presence as debounced state. A user switching networks should not produce an offline-then-online flicker. A short grace period before broadcasting offline removes most of the noise.
Receipts are lossy by design. Never let a missing receipt block message delivery, and never retry receipts as aggressively as messages.

The watermark model has a useful side effect: it makes unread counts consistent across devices without any extra synchronisation, because there is only one number to agree on.

The invariants I would put in a test suite

If I were writing the tests for a chat client from scratch, these are the ones that would catch the real bugs:

Sending the same message twice with the same client identifier results in one message in the conversation.
After a disconnect of arbitrary length, the client's message list matches the server's for that conversation, with no gaps and no duplicates.
Two clients that received the same messages in different arrival orders render the same order.
An unread count derived from a read watermark never goes negative and never exceeds the number of messages after that watermark.
A queued message survives an app restart and reports its state accurately.

None of these require an exotic test harness. They require the ability to drop and delay the connection deliberately, which is worth building early. A network-condition toggle in your debug build will find more real bugs than any amount of testing on a good connection.

Sources

Theming a Drop-In UI Kit Without Forcing a Fork

Vishal Singh — Thu, 08 Oct 2026 07:24:16 +0000

Theming a Drop-In UI Kit Without Forcing a Fork

Every prebuilt UI component library eventually meets a design system it was not built for. At that point the integrating developer makes one of three choices: accept the defaults, override with increasingly specific CSS, or copy the source into their repository and stop taking updates.

The third outcome is the expensive one. It looks like success in the sprint it happens and becomes a maintenance liability for years, because the fork no longer receives fixes, accessibility corrections, or new platform behaviour.

I work on developer-facing UI Kits at CometChat, where the whole value proposition is that a team drops in a conversation interface instead of building one. That makes forking a product failure, not a customer mistake. It has forced me to think about customisation as an API with a compatibility contract, rather than as a styling convenience.

The layered model

Customisation requests are not one thing. They arrive at four different depths, and each needs its own mechanism.

Depth	What the developer wants	Mechanism
Tokens	Brand colours, radius, type scale, spacing	CSS custom properties
Component styling	This one button looks wrong in our layout	Documented class or style hooks per component
Composition	Add a field, reorder the header, remove an action	Slots and render props
Behaviour	Different data source, different send pipeline	Headless core with the UI as an optional layer

The failure mode is offering only the first and the last: a colour variable and ""you can build it yourself"". The middle two are where real integrations live.

Tokens are the contract you will never be able to change

CSS custom properties are the right substrate for the token layer because they cascade, they can be scoped per subtree, and they cost nothing at runtime. They also become a public API the moment you document them.

.my-app-chat {
 --cc-color-primary: #2b6cb0;
 --cc-color-surface: #ffffff;
 --cc-radius-md: 10px;
 --cc-font-family: ""Inter"", system-ui, sans-serif;
}

Two decisions matter more than the names:

Semantic, not literal. --cc-color-primary survives a redesign; --cc-color-blue-500 does not. Literal names force you to either lie or rename, and renaming is a breaking change.

Every internal value resolves through a token. The moment one component hardcodes a hex value, the theme has a hole in it, and the developer who finds that hole reaches for !important. That is the first step towards the fork.

Support dark mode by redefining tokens under both a prefers-color-scheme query and an explicit attribute selector, so a host application that has its own theme toggle can drive yours.

Slots are what stop the fork

Most ""we had to fork it"" stories are not about colour. They are about structure: the team needed an extra action in the message header, a custom empty state, a badge next to a name, their own attachment picker.

If your components accept slots for their meaningful regions, those requests are satisfied without touching your internals:

<MessageList
 renderHeader={(conversation) => <OurHeader conversation={conversation} />}
 renderMessage={(message, Default) =>
 message.type === ""order"" ? <OrderCard message={message} /> : <Default />
 }
 renderEmptyState={() => <OurOnboardingPrompt />}
/>

Note the second argument in renderMessage. Passing the default renderer back into the override is a small thing that changes the economics: developers can special-case one message type without reimplementing the other fifteen. Overrides that require all-or-nothing replacement get used all-or-nothing.

Escape hatches, deliberately placed

You will not anticipate every requirement, so plan the exit. A headless layer - hooks or plain functions that expose state and actions without markup - lets a team keep your data handling and connection management while writing their own UI. That is a customer who still gets your bug fixes.

The rule I try to hold to: any escape hatch should degrade one layer at a time. Wanting custom markup for the composer should not mean giving up presence handling, and wanting a different send pipeline should not mean giving up the message list.

Versioning: the part that decides whether upgrades happen

A UI Kit has a wider public surface than a normal library, and much of it is not in the type definitions. Class names people style, token names they set, DOM structure they select against, slot signatures, default visual behaviour - all of it is API in practice.

So the policy has to be explicit:

Documented tokens, slots, and class hooks follow semver. Renaming one is a major version.
Internal class names are namespaced and documented as unstable, and the docs say what to use instead.
Visual changes that alter layout dimensions get called out in release notes even when no code changed, because they can break a host page's surrounding layout.
Deprecate in two steps: keep the old name working alongside the new one with a console warning, then remove it in the next major. A deprecation that ships and removes in the same release is just a break with extra words.
Ship a migration note with a code example per breaking change. Upgrade friction is why people stay on old majors, and people on old majors file bugs you already fixed.

Accessibility is not a customisation option

One asymmetry is worth stating: theming should not be able to break keyboard navigation, focus visibility, roles, or contrast. Tokens that control colour should ship with documented contrast expectations, and focus indicators should not be removable through the theme layer alone.

If a developer has to choose between matching their brand and keeping the component accessible, the design of the theming layer is at fault, not the developer.

The test I apply

Before shipping a customisation feature, I ask: does this let someone satisfy the request without reading our source? If the answer is no, they will read the source, and once they have read it, copying it is a short step.

A UI Kit is measured by how many teams are still on a recent version a year later. Every customisation mechanism above exists to make that number higher.

Sources

The buyer-seller conversation nobody owns

Nivedita Bharathy — Wed, 23 Sep 2026 07:12:47 +0000

Buyer-seller chat sounds simple.

Until someone sends their phone number and suddenly the conversation is happening outside your marketplace.

That’s where things get interesting.

You’re not just building a chat UI anymore. You’re dealing with contact sharing, message history, disputes, moderation, deleted messages, and giving support teams enough context to figure out what actually happened.

And there’s a bigger question underneath all of it:

Who actually owns the conversation?

If the chat is part of the transaction, it probably needs to be treated as more than just another messaging feature.

We got into some of the engineering problems around this here ↓

https://www.cometchat.com/blog/the-buyer-seller-conversation-nobody-owns

Classroom chat is a moderation problem

Nivedita Bharathy — Wed, 23 Sep 2026 07:06:21 +0000

Classroom chat is a UX problem until you have to moderate it.

Then the engineering questions start piling up.

Who can message whom?
What happens when a student sends something inappropriate?
Do teachers see every message?
What gets flagged automatically?
What happens across different roles, channels, and age groups?

The chat UI is the easy part.

The hard part is building the moderation layer underneath it without turning the experience into a maze of restrictions.

We dug into what that actually looks like when you're building chat for classrooms ↓

https://www.cometchat.com/blog/the-classroom-chat-is-a-moderation-problem-wearing-a-ux-costume

Third-Party Scripts Are the Real Performance Budget on a CMS-Driven Site

Vishal Singh — Mon, 21 Sep 2026 10:50:45 +0000

A developer-facing marketing site has an awkward property: the people who publish to it every day are not the people who own its performance. Content editors add a demo embed, a webinar form, a chat widget, a heatmap tool. Each addition is reasonable on its own. The page is measurably worse a quarter later, and no single commit caused it.

I run into this on the CometChat website, which is built on a headless CMS with components that marketing composes freely. Our own product is an embeddable SDK, so the problem is not abstract to me: we ship a script that other people put on their pages, and we host pages that carry other people's scripts. Both sides of that trade have the same lesson.

First, measure what the user experiences, not what your laptop does

Lab tools tell you whether a page can be fast. Field data tells you whether it is. On a CMS site the gap is usually caused by content, not code: a hero image an editor uploaded at full resolution, an embed added to one template, a font swapped on a single landing page.

The three metrics worth arguing about:

LCP is nearly always an image or a web font on marketing pages. It is a content problem more often than a delivery problem.
INP is where third-party JavaScript shows up. A tag manager that evaluates on the main thread during page load competes with your own hydration.
CLS is where late-loading embeds and consent banners live. Anything that inserts DOM after first paint needs reserved space.

Segment field data by template, not just by URL. "Our blog is fine and our pricing page is not" is an actionable sentence. "The site scores 74" is not.

The audit that actually changes behaviour

Rather than a one-off cleanup, produce an inventory that a non-engineer can read. For every third-party script:

Question	Why it decides the outcome
Who asked for it, and for what decision?	Half of them are answering a question nobody asks any more
What does it cost in transferred bytes and main-thread time?	Bytes are cheap to quote; main-thread time is what users feel
Does it need to run before interaction?	Almost nothing does, except consent and A/B testing
Does it insert DOM?	If yes, it needs reserved layout space
What happens if it fails?	It must be able to time out without blocking anything

I have never run this inventory without finding at least one script still loading for a campaign that ended.

Guardrails beat cleanups

A cleanup lasts until the next campaign. Guardrails last longer, and they belong in the CMS layer where the content is composed:

No raw HTML embed field. If editors can paste a <script> tag into a rich-text field, your performance budget is advisory. Replace it with typed components: a video component, a form component, a code-sample component. Each one is implemented once, lazily, correctly.
Media handled by the pipeline, not the uploader. Resize, compress and serve modern formats at the component boundary. Give images explicit dimensions from the CMS asset metadata so layout is stable before the bytes arrive.
Defer everything that is not needed for first interaction. Chat widgets, heatmaps, and video players load on interaction or on viewport entry. A chat launcher is a button; the widget itself can arrive after the click.
Budgets in CI, on templates. Fail the build when a template's script weight or estimated main-thread time crosses a line. The failure message should name the component that grew.
A single owner for the tag list. Tags added directly through a tag manager bypass every check above. That is the hole in most otherwise-good setups.

Point 3 is where the largest wins are, and it is also the one that most often gets reversed by a stakeholder who wants their widget "available immediately". Have the number ready: what interaction latency costs in conversion is a more persuasive argument than what it costs in milliseconds.

The other side: shipping a script other people embed

Building an embeddable product changes how you read your own audit. If your SDK is on someone's landing page, you are the third-party script in their inventory, and they will run exactly the questions above against you.

What that implies, in the order the questions get asked:

Ship a small loader and fetch the rest on demand. A launcher button does not need the full conversation runtime.
Do your initialisation work off the critical path, and never block first interaction on a network round trip.
Reserve your own space. If your widget mounts into a fixed-position container with known dimensions, you contribute nothing to CLS.
Fail invisibly. If your API is unreachable, the host page must still be fully usable.
Publish your weight. Teams that are auditing scripts will pick the vendor whose numbers are documented over the one whose numbers require a WebPageTest run.

Those are the same constraints, viewed from the other end. The audit you run on your own site is the audit your customers run on you.

What I would do first

If you inherit a slow CMS-driven site, resist the rewrite. Do this instead:

Pull field data, grouped by template.
Inventory third parties with owners named.
Delete the ones nobody defends.
Convert the remaining critical-path scripts to interaction-loaded.
Replace the raw HTML field with typed components so the problem stops regenerating.

Steps 1 to 4 recover most of the loss. Step 5 is the one that keeps it recovered.

Sources

Weekly news roundup: The moat moved off the model, onto everything around it.

Shrinithi V — Mon, 21 Sep 2026 08:12:02 +0000

TSMC bets $31 billion on AI's future

What's going on?
TSMC is dropping $31.4B on three new Taiwan fabs for sub-1.4nm chips with AI data centers now making up two-thirds of its revenue, up from smartphones.

Why it matters?
More advanced silicon means more horsepower for AI. But the first fab won't ship until ~2030, so the compute crunch everyone's feeling isn't easing anytime soon.

How we see this at CometChat
Every AI agent including the ones answering support chats and moderating conversations runs on this silicon. The smarter agents get, the hungrier they are for compute. Worth watching who's actually building the supply.

The AI lead just changed hands

What's going on?
Anthropic is weighing a new model launch after OpenAI's GPT-6 Astra pulled ahead in enterprise spend - days after Anthropic's CEO publicly urged the whole industry to slow down.

Why it matters?
A two-and-a-half-year lead just cracked. When frontier labs sprint, the models under your apps get smarter and cheaper faster than your roadmap can react.

How we see this at CometChat
‘Slow down’ one week, ‘maybe ship’ the next - the tension is real. But if you're building AI agents into your product, model churn is the actual story. Pick an abstraction layer that survives whichever lab wins the month.

Cancer-detecting AI is now free

What's going on?
Alibaba open-sourced Damo Radar - a model that spots nearly 150 abdominal diseases, including cancers, from CT scans, and it beat 23 of 26 radiologists in testing.

Why it matters?
A smaller hospital with no in-house AI team can now run expert-level diagnostics for free. When radiologists used it as an assistant, missed diagnoses dropped 10% and reads got 30% faster.

How we see this at CometChat
The pattern that makes this work - pairing images with clinical reports so the model actually understands context is the same reason AI agents are getting good at conversations. Context is everything. A model that reads the whole picture beats one guessing from fragments, whether it's a CT scan or a support thread.

One config file to rule them all

What's going on?
Claude Code now reads AGENTS.md - the open instruction format already used by Cursor, Codex, and 60,000+ repos so you stop maintaining a separate file for every AI coding tool.

Why it matters?
Fewer redundant configs, fewer symlink hacks. One markdown file tells every agent your build commands, test rules, and code style. Small change, real relief.

How we see this at CometChat
Standards winning over walled gardens is always the good ending. The same instinct applies to how AI agents plug into your product - shared, portable, boring-in-the-best-way conventions beat bespoke glue code that only one tool understands. Interoperability isn't glamorous. It's just what keeps things working.

Voice AI just got 13x cheaper

What's going on?
Google launched Gemini 3.8 Live - voice models that talk, see, switch across 97 languages mid-sentence, and run background tasks while chatting. Extended Thinking topped OpenAI's GPT-Live-1 on quality, at roughly 1/13th the cost.

Why it matters?
Real-time voice agents just went from ‘nice demo, wild bill’ to something you can actually run in production. Price was the wall. That wall's coming down.

How we see this at CometChat
‘Let me check that…’ while the agent works in the background - that's not a model detail, that's conversation design. Voice agents live or die on whether the interaction feels human under real latency. The model's getting cheap. Making it feel good is still the hard part.

Enterprise Chat Architecture in 2026: How In-App Chat is Actually Built at Scale

Shrinithi V — Sun, 20 Sep 2026 06:34:38 +0000

Enterprise chat architecture is the set of backend systems that move messages between users reliably, in order, and fast: a real-time connection layer for live clients, a durable event pipeline for ordering and delivery, tiered storage for history and media, and a presence layer for who's online. To keep this concrete, the examples here come from a real system instead of a generic diagram: CometChat's architecture, which runs across 113,000+ apps in 163 countries at a 99.999% uptime SLA. CometChat is a chat and messaging platform for developers, and working from an actual stack means naming real databases and real numbers, not vague claims about ‘scalable infrastructure.’

Get those four systems right and chat feels instant. Get one wrong and it feels instant right up until real load arrives. This is the engineering piece, not the buyer piece: if you're an architect or senior engineer deciding whether to build in-app chat or buy it, here's how the system actually works under the hood, and the parts most teams underestimate until they're debugging them at 2am

The four systems chat actually is

In-app chat is four coupled systems wearing one trench coat. Each has its own failure mode, and they fail on different nights.

Connection layer: persistent WebSocket connections, one per active client, carrying events in both directions.
Event pipeline: the durable log that decides ordering, guarantees delivery, and fans each message out to recipients.
Storage: where message history, metadata, and media live, each with a different access pattern.
Presence: who's online, typing, idle, or gone, updated in real time.

Build any one of these badly and you don't find out on launch day. You find out at scale, in production, in front of users who are not impressed.

Message delivery guarantees: what ‘delivered’ has to mean

A message delivery guarantee is the contract for whether a message can be lost, duplicated, or reordered when something fails. There are three flavors: at-most-once (fast, drops messages), at-least-once (safe, duplicates messages), and exactly-once (the one everyone wants on the whiteboard and nobody gets for free).

Real chat backends aim for effectively-once: idempotent producers, automatic retries, offline queuing, and sync across devices, so a flaky network produces one message on every device - not zero, and not three. CometChat's pipeline is built on exactly this set: effectively-once semantics using idempotent producers, retry logic, offline message queuing, and synchronization across a user's devices.

The happy path is not the problem. The problem is the client that dropped into a tunnel mid-send, reconnected four minutes later, and expects its message to land once, in the right order, on the phone and the laptop and the web tab it forgot to close. Ordering and deduplication under failure are the actual product. Everything else is UI.

This is why serious stacks put a real commit log in the middle. CometChat uses Apache Kafka as the event backbone: guaranteed message ordering, no message loss, sub-second latency, and configurable retention. The log is what lets you make promises about ordering that survive a retry without one, ‘in order’ is a hope, not a guarantee.

Presence: the feature that lies to you

Presence is the system that tracks who's online, typing, or idle, in real time, across every device. It sounds simple. It is not, and it tends to prove that in front of users.

Presence is high-frequency, low-value, and unbounded - the worst combination in distributed systems. Every keystroke can fire a typing event. Every reconnect can fire an online event. Open a group with 3,000 members and, done naively, you've signed up to push 3,000 presence updates to every one of them, continuously. That's not a chat feature. That's a self-inflicted DDoS with a green dot on it.

The fixes are unglamorous and mandatory: debounce typing events, batch presence changes, scope presence to the conversations a user is actually looking at, and treat ‘last seen’ as eventually consistent instead of real-time. CometChat handles presence and typing indicators over its WebSocket Gateway - persistent bi-directional connections with automatic reconnection and session recovery and exposes WebSocket-level control so you can define custom presence logic instead of accepting "is the socket open" as the answer. Because "is the socket open" is almost never the question you actually mean.

Fan-out at scale: where the math stops being cute

Fan-out is the work of turning one sent message into delivery events for every recipient's active connections. For 1:1 chat it's trivial. For a 10,000-member group where 3,000 people are online, each on two devices, one message becomes 6,000 delivery events (3,000 × 2) and something has to route all of them without tipping over.

Two things keep this sane. First, a connection layer that scales horizontally: CometChat runs on a stateless service design, so you add capacity by adding compute, not by re-architecting or migrating data. Second, the event log in the middle. With Kafka handling routing and ordering centrally, delivery is guaranteed once - not renegotiated per connection while 6,000 sockets wait.

Concrete numbers, since ‘highly scalable’ is a phrase and not a fact: CometChat's Docker Swarm tier is built for up to ~200,000 monthly active users and ~20,000 peak concurrent connections, at sub-100ms message latency. Past that - 200k+ MAU or multi-region - the deployment moves to Kubernetes. The whole platform is engineered from 10,000 to 250,000+ MAU with linear scaling. Those are the kind of numbers you want in a capacity plan, not adjectives.

Storage: one database is a lie you tell yourself early

Chat storage is polyglot by necessity. No single database is good at hot reads, durable history, media blobs, and rate-limit counters at the same time, and the classic early mistake is making one try. It works beautifully in staging and falls over the first quarter you have real history to query.

Here's how CometChat's on-premise stack splits the job:

Layer	What it stores	Technology	Why this one
Distributed SQL	Messages, conversations, users — the source of truth	TiDB (PD + TiKV with Raft, MySQL-compatible SQL layer)	ACID transactions, automatic sharding, multi-region replication, strong consistency
Document store	Moderation policies, custom metadata, webhook config, audit logs	MongoDB	Flexible schema, native JSON, rich queries on semi-structured data
In-memory	Cache, sessions, auth tokens, rate-limit counters	Redis clusters (cache + session/rate-limit)	Sub-millisecond latency for the highest-frequency operations
Object storage	Files, images, large binary attachments	S3-compatible (S3, MinIO, Ceph, GCS)	Lifecycle policies, versioning, encryption at rest, tiered cost
Event log	Ordering and delivery backbone	Apache Kafka	Guaranteed ordering, no message loss, configurable retention

The part people miss: message history grows forever and gets queried constantly. The database that felt fine at 10 million messages is a different animal at 10 billion, and by then you're not choosing a database - you're migrating one, live, while people are talking. Distributed SQL with automatic sharding exists so that day never arrives.

Data residency: the requirement that rewrites your topology

Data residency is the rule that a user's data must be stored and processed inside a specific legal jurisdiction. It is not a settings toggle. It's an architectural constraint that shows up before you write a line of code, because it dictates where your databases physically sit and how your regions replicate.

If you serve regulated industries or the EU, this decides your deployment model, not the other way around. CometChat supports the full range: managed cloud, private cloud in a specific region, hybrid, and fully air-gapped on-premise where data never leaves your infrastructure. It's built to meet GDPR, HIPAA, SOC 2, ISO 27001, CCPA, and PIPEDA, with encryption at rest, configurable key management, and secure WebSocket connections. Multi-tenancy gives you logical isolation with per-tenant configuration, rate limits, and quotas, which matters the moment one deployment serves several business units that legal insists cannot see each other's data.

The reframe worth keeping: residency isn't a feature you bolt on later. Retrofitting jurisdiction into a single-region system is a rebuild, not a config change. Decide it first.

Where it breaks at 2am

The four systems are the easy part to name and the hard part to keep alive. The failures that actually page you:

Reconnection storms. A region blips, thousands of clients reconnect at once, and your connection layer plus session store take the full spike simultaneously. Without session recovery and stateless gateways, this cascades.
Presence fan-out. The green dot that felt free in testing becomes the single largest source of traffic in production.
Group fan-out. Big groups turn one message into thousands of writes and pushes. Linear-looking code, quadratic-feeling bill.
Ordering under retry. Messages arrive, but out of order or twice, because the retry path didn't go through the log. Users notice instantly.
History queries. The read that was instant at launch times out once there's real backlog to scan.
Cross-region replication lag. Two users, two regions, one conversation, and a few seconds of disagreement about what was said.

None of these show up in a demo. All of them show up at scale. That's the whole reframe of operating chat instead of shipping it: the work isn't the feature, it's the years the feature has to keep working.

Build vs buy, without the sales pitch

Building this in-house is entirely possible - it's also months of work before your first message, and years of the failures above before it's boring. If chat is your core product and your differentiator, build it. If chat is a feature your product needs to have and keep working, the math usually points the other way.

Either way, now you know what the system is actually made of, and which parts to interrogate before you commit. If any of this resonated, that's the part worth getting right first.

CometChat's enterprise chat infrastructure, in one place

CometChat's enterprise infrastructure is the four systems above, already built and already surviving the 2am failures - a stateless WebSocket Gateway for connections and presence, an Apache Kafka backbone for ordered, no-loss delivery, polyglot storage (TiDB, Redis, MongoDB, S3-compatible object store) tuned per access pattern, and multi-tenancy with per-tenant isolation, rate limits, and quotas.

It runs where your compliance team needs it to: managed cloud, region-pinned private cloud, hybrid, or fully air-gapped on-premise where data never leaves your infrastructure - built to meet GDPR, HIPAA, SOC 2, ISO 27001, CCPA, and PIPEDA, with encryption at rest, configurable key management, and secure WebSocket connections. It scales linearly from 10,000 to 250,000+ monthly active users at sub-100ms message latency, on Docker Swarm up to ~200k MAU and Kubernetes beyond that.

The point isn't the feature list. It's that presence fan-out, ordering under retry, reconnection storms, and residency-driven topology are already handled - so your team ships the product and skips the years of learning which of these breaks first. Speed becomes sustainability. Shipping becomes operating. That's the whole trade.

Want to see the stack instead of read about it? Start for free and build against it, or contact sales if you're sizing a deployment for real load, data residency, or an on-premise rollout.

FAQ

What is enterprise chat architecture? It's the backend that delivers messages reliably, in order, and fast at scale - a real-time connection layer, a durable event pipeline for ordering and delivery, polyglot storage for history and media, and a presence layer. Enterprise adds data residency, compliance, and multi-tenancy on top.

What message delivery guarantee does chat need? Effectively-once: one message on every device, even after a dropped connection and retry. Pure exactly-once is expensive and rare, so real stacks combine idempotent producers, automatic retries, and offline queuing to reach effectively-once in practice.

How many concurrent connections can a chat backend handle? It depends on architecture, not vibes. CometChat's Docker Swarm deployment targets ~20,000 peak concurrent connections and ~200,000 MAU at sub-100ms latency; beyond that, Kubernetes handles 200k+ MAU and multi-region, scaling linearly to 250,000+ MAU.

What database should I use for chat? More than one. Distributed SQL (like TiDB) for the message source of truth, Redis for hot cache and sessions, a document store for metadata and audit logs, object storage for media, and a log like Kafka for ordering. No single database does all of that well.

Do I need Kafka for chat? You need a durable, ordered event log; Kafka is the common choice. It's what lets you guarantee ordering and no message loss centrally, so those promises survive retries and reconnects instead of being renegotiated per connection.

How do I meet data residency requirements for chat? Decide the deployment model before you build. Options are managed cloud, region-pinned private cloud, hybrid, and air-gapped on-premise. CometChat supports all four and is built to meet GDPR, HIPAA, SOC 2, ISO 27001, CCPA, and PIPEDA. Retrofitting residency into a single-region system is a rebuild, so choose first.

Streaming an AI Agent Into a Chat UI: The Parts That Are Not the Model

Vishal Singh — Wed, 16 Sep 2026 08:24:22 +0000

Streaming an AI Agent Into a Chat UI: The Parts That Are Not the Model

Most write-ups about putting an AI agent in a chat product stop at the prompt. In practice, the model is the part you change least. The parts that break are message identity, tool-call rendering, thread context, and what the client does when a stream dies halfway through a sentence.

I work on messaging infrastructure at CometChat, where AI assistants and bots sit in the same conversation as human participants. That constraint is the interesting one: an agent reply is not a separate UI mode, it is a message in a thread that also has read receipts, reactions, threads, moderation, and history sync. Anything you invent for the agent has to survive contact with all of that.

Here is what I would insist on before wiring an agent into a chat surface.

1. A streaming reply is one message with many revisions

The naive implementation appends a message per chunk. It looks fine in a demo and falls apart the moment a second device is open, because now that device receives forty messages instead of one.

Model the reply as a single message with a stable identifier created at the moment the request is accepted, and a mutable body plus a state field:

pending - accepted, nothing generated yet
streaming - partial content, safe to render
complete - final content, safe to cache and index
failed - render the partial content plus an explicit error affordance

The client that started the request updates optimistically from the token stream. Every other client learns about the message through the same real-time channel it uses for human messages, and reconciles by identifier. In CometChat terms this is the difference between sending many messages and updating one message repeatedly, and it decides whether your history stays readable a week later.

Practical detail: throttle the update you broadcast. Rendering every token locally is cheap; fanning out every token to all participants and persisting each revision is not. Local stream at token granularity, remote update on an interval or on sentence boundaries.

2. Tool calls are message parts, not log lines

An agent that searches a knowledge base, files a ticket, or looks up an order produces intermediate steps. If you flatten those into prose, users cannot tell what actually happened, and you cannot audit it afterwards.

Give the message structured parts:

{
 ""id"": ""msg_01H..."",
 ""state"": ""streaming"",
 ""parts"": [
 { ""type"": ""text"", ""text"": ""Checking your last invoice."" },
 { ""type"": ""tool_use"", ""name"": ""lookup_invoice"", ""args"": { ""id"": ""..."" }, ""status"": ""running"" },
 { ""type"": ""text"", ""text"": """" }
 ]
}

Two things fall out of this for free. The UI can collapse tool activity behind a disclosure instead of interleaving it with the answer. And moderation, analytics, and export can treat tool_use differently from text, which matters when the tool arguments contain customer data you do not want in a search index.

The metadata field on a chat message is usually the right place to carry this. Keep the human-readable summary in the message body so that clients you have not updated yet still show something sensible.

3. Thread context is a retrieval problem, not a window problem

""Send the last N messages"" is the default and it is wrong in both directions. In a support conversation, N=50 can be six months of small talk; in a fast group chat, N=50 is four minutes.

What has worked better as a starting policy:

always include the last few turns verbatim, because coreference lives there (""no, the other one"")
include a rolling summary of the conversation, regenerated on a cadence rather than per message
retrieve by relevance from the rest of the thread and from your own docs, and label retrieved content as reference material, not as conversation
carry participant and channel facts explicitly (locale, plan, entitlement) instead of hoping they appear in the transcript

And treat everything from the thread as untrusted input. A message in a group chat can contain instructions aimed at your agent. If your agent has tools that write - refunds, escalations, invites - then a user-authored message is an attacker-authored message. Authorise tool calls against the requesting user's own permissions, not the agent's.

4. Failure states need a design, not a spinner

Streams break: the socket drops, the model provider rate-limits you, generation is cut mid-token. Decide in advance what each one looks like.

Failure	Behaviour
Socket drops mid-stream	Keep the partial message, mark it interrupted, resume or offer retry by message id
Provider error before any token	Move message to `failed`, show retry, do not leave an empty bubble
Timeout with no response	Read back the message state before retrying; a missing response does not prove nothing was generated
Retry after partial output	Replace the body of the same message id, never append a second reply

That last row is the one teams get wrong. Retries must be idempotent at the message level, keyed on the request identifier the client generated. Otherwise every flaky connection produces duplicate assistant replies, and the transcript stops being a record of what happened.

5. The agent is a participant, so give it an identity

If the agent posts as a bot user with its own identifier, everything downstream works: mentions, per-conversation muting, permissions, rate limits, moderation rules, and analytics that can separate human from generated volume. If it posts as a magic side channel, you will re-implement each of those badly.

This is also how you keep the door open for more than one agent. A triage bot and a summariser bot in the same channel are just two participants with different tool scopes.

Why this matters more than prompt tuning

You can swap models in an afternoon. You cannot easily change the shape of a million stored messages. The decisions that age well are the boring ones: stable message identity, structured parts, explicit states, idempotent retries, and an agent that lives inside your existing permission model rather than beside it.

If you are adding an assistant to a product that already has real conversations in it, design the message first and the prompt second.

Sources

News Roundup: Compute got scarce. Efficiency stopped being optional.

Shrinithi V — Mon, 07 Sep 2026 15:51:37 +0000

AI That Finds Its Own Zero-Days

What's going on?
OpenAI launched GPT-6 Astra - the first model that can independently discover and exploit unknown software vulnerabilities, and it's pairing that with $1B for cyber defenders.
Why it matters
Attackers get frontier tools the day they ship. Now defenders do too but only if they move first. The gap between ‘we should patch that’ and ‘someone already did’ just got shorter.
What we think at CometChat
Same story we know well: capability without accountability breaks things at scale. Powerful AI agents - in security or in chat need guardrails built in, not bolted on later. Ship fast, but ship safe.

Samsung and Arm Build 2nm AI Chip

What's going on?
Samsung and Arm kicked off a custom 2nm chip built to run AI directly on your device with OpenAI rumored to be the end customer.
Why it matters
On-device AI means less round-tripping to the cloud. Lower latency, less dependence on someone else's servers, and inference that happens where your users actually are.
What we think at CometChat
The whole industry is quietly moving intelligence closer to the edge. For chat and AI agents, that's the good direction - faster responses, private by default. The interesting part isn't the silicon. It's what you build on top of it.

Chip Gear Spending Hits Record $40B

What's going on?
Semiconductor equipment billings hit a record $40.53B last quarter - the second record in a row as chipmakers race to build capacity for AI.
Why it matters
Memory is booked solid through 2027, and new capacity won't land before 2028. Translation: the compute powering your AI features is getting pricier and scarcer, not cheaper.
What we think at CometChat
When infrastructure is this constrained, efficiency stops being optional. For AI agents and chat at scale, every wasted call costs real money. The teams that win won't be the ones with the most compute - they'll be the ones who waste the least.

$3.5B Bet on Humanoid Robots

What's going on?
Nscale is committing $3.5B in compute (scaling to $6B+) to power Figure's humanoid robots 100,000 Nvidia GPUs, plus an equity stake in the robotics startup.
Why it matters
Physical AI is getting real money and real infrastructure. Robots that learn, adapt, and operate in the world all run on the same thing your software does: massive, expensive compute.
What we think at CometChat
The line between ‘AI in an app’ and ‘AI in a body’ is thinner than it looks. Both need the same foundation - models that respond fast and reliably. Whether it's a robot in a warehouse or an agent in a chat, the hard part was never the demo. It's making it work every time.

Xiaomi Debuts Its Own 3nm Chips

What's going on?
Xiaomi unveiled three in-house chips at IFA - a 3nm flagship phone SoC, an edge AI accelerator, and an autonomous driving chip reducing its reliance on Qualcomm and MediaTek.
Why it matters
When a company owns its silicon, it controls the whole stack - performance, power, and how AI runs on-device. That's tighter integration and less waiting on someone else's roadmap.
What we think at CometChat
The edge AI chip is the one to watch - 330 tokens per second, running inference right on the device. As more intelligence moves on-device, chat and AI agents get faster and more private by default. The demo is easy. Owning the whole pipeline is the hard, smart part.

Google Recycles Old Chips to Survive

What's going on?
Google is pulling DDR4 memory from retired servers and adapting it for new AI machines - a stopgap as the memory shortage bites and prices climb up to 90% in a quarter.
Why it matters
Even the biggest players can't buy their way out of this. Memory now eats ~30% of hyperscaler budgets, up from 8% two years ago. The cost of running AI is being reshaped by a shortage that lasts through 2030.
What we think at CometChat
Efficiency just became a survival skill. When compute and memory are this scarce, the winners aren't the ones spending the most - they're the ones getting more out of less. For AI agents and chat at scale, lean beats lavish. Every wasted call has a price now.

News Roundup: The frontier moved from "can it?" to "can you trust it?"

Shrinithi V — Thu, 03 Sep 2026 08:32:49 +0000

Gemini Now Runs Your Tasks Solo

What's going on?
Google gave Gemini Live an agentic upgrade - you speak a goal out loud, and it runs multi-step tasks across Docs, Sheets, Gmail, and Drive on its own.
Why it matters?
Voice stops being just Q&A. Assistants now remember your intent and act on it for days - no app-switching, no babysitting the workflow.
How we see it at CometChat
This is where conversation becomes the interface. The hard part isn't making an agent talk, it's making it act reliably across a real product. Agents are only as good as the messaging layer they run on.

Nvidia's Robots Just Hit $10 Billion

What's going on?
NVIDIA's physical AI arm - chips for robots, self-driving cars, and drones now pulls in ~$10B a year, with China shipping 97% of the world's humanoid robots.
Why it matters?
The ‘ChatGPT moment’ for robots isn't coming - Huang says it already passed. Physical AI is scaling from demos to factory floors, fast.
How we see it at CometChat:
A robot that moves is impressive. A robot you can actually talk to, that understands context and responds in real time - that's the harder problem. Intelligence in hardware still needs a conversation layer that doesn't fall over.

Meta's New Agent Shops, Books, and DJs

What's going on?
Meta is testing ‘Project Hatch’ - a personal AI agent with its own computer that books restaurants, orders food, buys gifts, and even runs your Spotify, all in the background.
Why it matters?
Agents are moving from answering questions to taking actions across your real apps and accounts - email, calendar, OpenTable, DoorDash. The interface is becoming a delegate.
How we see it at CometChat
Handing an agent your calendar is easy. Handing it your conversations is where trust gets real. When agents start acting on your behalf, the messaging layer has to be reliable, secure, and legible because ‘it booked the wrong thing’ is a much bigger problem in production than in a demo.

Google's AI Video Now Directs, Not Just Generates

What's going on?
Gemini Omni 1.1 Flash adds 4K upscaling, keyframe transitions, and scene extension up to 40 seconds giving AI video an actual beginning, middle, and end.
Why it matters?
The pitch shifts from ‘generate a clip’ to ‘direct a scene.’ Cheap 360p drafts, polished 4K finals - a workflow real production teams can actually use.
How we see it at CometChat
Every leap in AI-generated content raises the same question: how do people talk about it, react to it, share it? Richer media only matters if the room around it - comments, threads, live reactions can keep up. The content gets better; the conversation layer has to too.

AI Guides World-First Brain Tumour Surgery

What's going on?
Surgeons in London removed a brain tumour using real-time AI that colour-coded critical vessels and nerves on a live video feed - saving a 48-year-old's eyesight.
Why it matters?
AI as an ‘expert second pair of eyes,’ trained on more operations than a surgeon sees in a lifetime. Not replacing the human rather assisting the highest-stakes decisions in real time.
How we see it at CometChat
The surgeons kept full control the whole way - the AI advised, humans decided. That's the model that works. Whether it's an operating theatre or a support chat, the best AI doesn't take over the conversation. It gives people better information at the moment they need it, and lets them make the call.

Hyundai Bets Big on Self-Driving by 2028

What's going on?
Hyundai and NVIDIA are teaming up to put Level 2+ self-driving in mass-market cars by 2028, backed by a 50,000-GPU data centre and an in-house AI system.
Why it matters?
Self-driving stops being a luxury demo. When 12 of every 20 new cars in China already ship with Level 2+, autonomy becomes a standard feature buyers expect, not a moonshot.
How we see it at CometChat
Hyundai's whole bet is the ‘data flywheel’ - collect, train, deploy, repeat. Same logic applies to how products talk to users: every conversation is a signal. The teams that win aren't just shipping AI features, they're building the feedback loop that makes each interaction smarter than the last.

CometChat Cards

CometChat — Thu, 03 Sep 2026 08:15:47 +0000

Most of what people send each other in a chat isn't really a sentence. Someone shares an event, and the date, location, and RSVP link should travel together. A group admin posts an announcement that deserves more than a wall of text. A friend drops a link that needs a clear next step attached, not just a bare URL. In a 1:1 or group conversation, all of that gets squeezed into plain text, because there's never been a way to send something more structured than a message bubble.

CometChat Cards fixes that. A card carries a block and renders natively, as images, buttons, and layouts, right inside the same 1:1 or group chat window a text message would appear in.

Why does this matter to me as a developer building chat experiences?

Every custom message type you've ever built for a chat app followed the same path: design the payload, write a renderer for it, wire up the actions, repeat for the next one. It doesn't scale past the first few designs, and every platform you support means doing it again.

CometChat Cards take that off your plate. Design a card once, visually, in the CometChat Dashboard, and every UI Kit that supports the format renders it the same way, no custom parsing required.

Key features and capabilities

Card Builder, a visual editor in the Dashboard.
Build cards from 20 elements across four groups: content (text, markdown, image, icon, avatar, badge, chip, code block), layout (row, column, grid, accordion, tabs, divider, spacer), interactive (button, icon button, link), and data (table, progress bar). Four elements, button, icon button, link, and chip, can carry an action, and there are nine kinds to choose from: open a URL, start a chat with a user or group, send a message, copy to clipboard, download a file, initiate a call, hit an API, or run a custom callback in your app.
Nine starter components.
Product Card, Order Confirmation, Order Tracking, Event Card, Announcement, Quick Reply Buttons, Feedback, Data Table, and Carousel come pre-assembled, so you're editing instead of building from a blank canvas.
Variables
Insert placeholders like {{user.name}} anywhere in a card's text or URL fields, and CometChat fills them in per recipient when the card sends.
Built into every UI Kit.
Card messages are rendered automatically across all CometChat UI Kits. When a card message appears in a conversation, the UI Kit detects it and displays the appropriate card interface without any additional setup.
No wiring required
Card messages are handled internally by the UI Kit, so they work out of the box in CometChatMessageList and other standard conversation views across all supported platforms.
Fallback text
Every card includes fallback text. If the card JSON is malformed or a client doesn't support cards yet, the UI Kit falls back to that text instead of showing nothing, so the message still says something.

Where this shows up

CometChat already builds for these industries. Card Builder's starter components map onto what's already happening in each one's 1:1 and group chats:

Marketplace
A buyer and seller are already negotiating a listing in 1:1 chat. A Product Card carries the photo, price, and condition inline instead of the buyer switching to a listing page, and an Order Confirmation card closes the loop once they agree.
On-demand services
Customer and provider are coordinating a job in real time. An Order Tracking card shows live status and ETA right in the thread, the same conversation where they're already discussing pickup details or a delivery photo.
Education
A teacher posts to a class group chat. An Announcement or Event Card carries a session time, a join link, and an RSVP button, instead of the group scrolling past three separate messages to piece it together.
Gaming
A clan or guild group chat gets patch notes, a Data Table of leaderboard standings, or a Carousel of upcoming tournaments, laid out the way a status update actually reads instead of a wall of patch numbers.
Marketplace
A buyer and seller are already negotiating a listing in 1:1 chat. A Product Card carries the photo, price, and condition inline instead of the buyer switching to a listing page, and an Order Confirmation card closes the loop once they agree.
On-demand services.
Customer and provider are coordinating a job in real time. An Order Tracking card shows live status and ETA right in the thread, the same conversation where they're already discussing pickup details or a delivery photo.
Education
A teacher posts to a class group chat. An Announcement or Event Card carries a session time, a join link, and an RSVP button, instead of the group scrolling past three separate messages to piece it together.
Gaming
A clan or guild group chat gets patch notes, a Data Table of leaderboard standings, or a Carousel of upcoming tournaments, laid out the way a status update actually reads instead of a wall of patch numbers.
Healthcare
A patient and provider are messaging 1:1. An Event Card carries an appointment time with a reschedule button attached, or a Feedback card collects a quick check-in after a visit, without either side leaving the thread.
Dating
Two matches are talking. Quick Reply Buttons turn a common question into a tap instead of a typed reply, and a Carousel can surface shared interests or icebreaker prompts inline.
Community and social.
A group admin drops an Event Card for a meetup with an RSVP action, or an Announcement card for a rule change, so it reads as distinct from the conversation instead of getting lost in it.
SaaS businesses
A workspace or support channel gets a Data Table showing open ticket status, or an Announcement card for a new feature, sent to a group the same way any other message would be, just structured.

Reference links

Card Bubble component docs

CometChat Card Builder overview

Elements and actions reference

Card messages in the JavaScript SDK

CometChat Support Services: Built to support you at every stage

CometChat — Tue, 07 Apr 2026 07:59:34 +0000

When you add real-time communication to your product, be it chat, calls, or AI-driven conversations, reliability becomes critical. Your users expect conversations to work instantly and consistently.

That’s why support at CometChat is designed to go beyond troubleshooting. It combines immediate assistance, self-serve resources, proactive guidance, and enterprise-grade guarantees to help teams build, launch, and scale confidently.

Here’s a closer look at the support services available.

1. Always-On Assistance

When something breaks or a question blocks progress, you need help quickly. CometChat provides multiple ways for teams to get real-time assistance.

24/5 Live Chat Support for instant help with urgent questions
24/5 Email Support for technical queries and troubleshooting
Ticket Support for structured issue tracking
24/7 Emergency Ticket Support for critical incidents

These channels ensure developers and product teams can reach support when they need it, whether during development, testing, or production incidents.

2. Knowledge & Self-Serve Resources

Many teams prefer to move quickly without waiting for assistance. To support this, CometChat provides a comprehensive set of learning resources.

Documentation with detailed implementation instructions
Help Center for quick answers to common questions
Tutorials & Guides to walk through integrations step-by-step
Community Forum for peer discussions and shared solutions
Status Page to monitor system availability and incidents
Feature Request Page to submit product feedback and ideas

These resources help teams integrate features like in-app messaging, moderation workflows, and communication infrastructure without friction.

3. Dedicated Access

For teams operating at scale or building complex communication experiences, direct collaboration with experts can make a major difference.

CometChat offers several options for closer engagement:

Dedicated Slack channel for real-time collaboration with support engineers
Dedicated Customer Success Manager to guide product adoption and strategy
Dedicated Technical Support Engineer for deep technical troubleshooting
Annual Technical Health Check to review architecture, performance, and best practices

This level of access ensures teams always have an expert who understands their implementation and can help optimize it over time.

4. Implementation Guidance

Launching a real-time communication feature can involve architectural decisions, integration challenges, and product design considerations. CometChat helps teams navigate this process through hands-on guidance.

Support includes:

Launch call with an Implementation Manager to review setup and deployment
Dedicated Implementation Engineer for complex integrations
Dedicated Slack channel during implementation for quick coordination

This guidance helps teams avoid common mistakes and get their messaging or calling features live faster.

5. Reliability & Escalation Support

For organizations running mission-critical communication systems, additional escalation paths are available.

These include:

Uptime SLA guarantees (up to 99.999%)
24/7 emergency phone support
24/7 priority email support

These options ensure rapid response and stronger reliability commitments when communication features are central to the product experience.

6. Advanced Technical Support & Optimization

As products evolve, teams often need deeper assistance with scaling, customization, or infrastructure changes.

CometChat provides advanced technical support such as:

Migration assistance when moving from another provider or legacy system
Integration reviews to validate architecture and configuration
Weekly check-ins for ongoing guidance and optimization
UI Kit integration and bespoke customization support

This support ensures teams can fully leverage the platform while maintaining performance and scalability.

7. Live Monitoring & Troubleshooting

Some use cases such as live events, launches, or high-traffic community moments require active oversight.

To support these scenarios, CometChat offers:

Virtual event live monitoring and support
Real-time troubleshooting during critical events

Having engineers actively monitor systems during important moments reduces risk and ensures rapid issue resolution if anything unexpected occurs.

8. Support Prioritization & Response Guarantees

As your product grows, so does the need for faster, more predictable support. CometChat’s support tiers ensure your most critical issues are handled with the urgency they deserve with defined response times and priority-based escalation.

Support plans include:

Guaranteed ticket first response times
Priority Support
Highest Priority Support

These tiers ensure that as your product scales, your support experience scales with it with faster response times, quicker escalations, and greater attention to critical issues when it matters most.

Built to support you at every stage

Adding communication features to your product introduces new complexity from infrastructure and scaling to moderation and reliability.

CometChat’s support services are designed to help teams navigate this complexity with confidence, combining immediate assistance, expert guidance, and enterprise-level reliability.

Whether you’re launching your first in-app messaging experience or operating communication features at global scale, the right support ensures your conversations never stop.