Design an E-Commerce Chat Forum

Problem statement

Design an e-commerce chat forum: an internal community where customers discuss products, ask and answer questions, share usage tips, and help each other. It is not a standalone social network. Every thread is anchored to a product or a product category, and the platform's commercial value comes from that binding: a shopper reading a product page sees real questions from real owners, and a helpful answer can move a purchase decision.

The problem requires four functional pillars: threaded discussions per product or category, verified-purchase badges, moderation tooling for spam and off-topic content, and an optional karma or reputation score. It also requires four non-functional pillars: full-text search across posts, scalability for large user interaction, caching for popular threads, and integration with the platform's existing user authentication system.

Why the problem is distinctive

A generic forum can treat identity as self-declared and trust as uniform. A commerce forum cannot. The single most important design lever is that we already know, from the order system, whether a given user actually bought the SKU being discussed. That lets us attach a verified-purchase badge to a post, rank verified answers above unverified ones, and give moderators a strong signal when a glowing thread is being seeded by accounts with no purchase history. This join between the forum and the order graph is what competitors usually skip, and it is the core of a strong answer.

The second distinctive property is the traffic shape. Forums are overwhelmingly read-heavy, and in a commerce setting the read amplification is extreme: a single popular product page can render the same top questions thousands of times a second during a sale event. The write path is comparatively small but it must pass through a trust-and-safety pipeline, because user-generated content at commerce scale attracts spam, promotional abuse, and coordinated manipulation of purchase sentiment.

The four architectural planes

1. Content plane: threads, posts, comment trees, edits, and the read/write paths that serve them.
2. Identity and trust plane: authentication via the existing user system, verified-purchase resolution, and reputation scoring.
3. Trust-and-safety plane: ingestion filtering, asynchronous classification, human review, and enforcement.
4. Discovery plane: search indexing, product-page projections, ranking, and notification fan-out.

A strong answer keeps these planes separate. The content plane must stay available and consistent for readers even while the moderation plane is slow or degraded, and the discovery plane must be able to rebuild its projections from the content plane without corrupting it.

Scope note on sensitive content

This design includes a trust-and-safety subsystem described strictly at the architecture level. It names real moderation services and quotes real latency and throughput budgets, but it never reproduces examples of abusive text, banned-word lists, or sample violations. Where code needs to reference a policy, it uses neutral placeholders such as denylistEntry, flaggedTerm, or TOXIC_CATEGORY_A. This is deliberate: the moderation pipeline is about routing, scoring, and enforcement, not about the content itself.