DEV Community: Subhash Adhikari

How We Designed a Production-Grade Communication Layer for an Investment Platform

Subhash Adhikari — Fri, 20 Feb 2026 17:46:46 +0000

Most teams building "groups and channels" underestimate how complex it gets when you add paid subscriptions, archive cutoffs, re-subscribe backfill logic, secure media, realtime delivery, and audit/compliance needs.

We recently designed a standalone Communication Layer for an investment platform that needed:

📢 Admin-only broadcast channels
💬 Structured discussion forums
💰 Subscription-aware access control
🔒 Secure media delivery
⚡ Horizontal scalability
🧱 Full decoupling from payments/courses

Here's how we approached it.

📢 Broadcast Channels — Store Once, Read Many

We avoided fanout-on-write (writing per subscriber). Instead:

Each post is stored once per channel
Each channel has a monotonic sequence number
Clients fetch using after_seq
Realtime pushes IDs only — (channel_id, seq, post_id)
Full content is fetched via REST (with access checks)

Why this matters

Fanout-on-write breaks at scale. With store-once:

1M users → still 1 DB row per post
Catch-up is deterministic
No duplication bugs
Easier pagination

Example feed fetch

GET /api/mobile/channels/{id}/posts?after_seq=120&limit=20

SELECT *
FROM posts
WHERE channel_id = $1
  AND seq > $after_seq
ORDER BY seq ASC
LIMIT $limit;

Simple. Predictable. Scalable.

💬 Forums — Clean Separation from Broadcast

We intentionally separated broadcast from discussion.

Structure:

Forum
  └── Topic
        └── Message

forums → discussion room
topics → thread
messages → replies

This prevents:

Announcement feeds turning into chat spam
Mixing system-critical updates with noise
Moderation chaos

Think: Telegram Channel + Linked Group or Reddit Subreddit → Post → Comment

💰 Subscription-Aware Access (Without Coupling Payments)

The most important design decision:

The Communication Layer knows nothing about subscriptions.

Instead, it calls an Access Provider:

canReadChannel(userId, channelId) -> AccessDecision

AccessDecision:
  mode: FULL | ARCHIVE_UNTIL | DENY
  read_windows?: [{start?, end?}]

Why this is powerful

Courses can map to channels
Subscription passes can expire
Premium users can retain archive-only access
Re-subscribe can restore with partial backfill
All without polluting channel logic

The Communication Layer enforces only: FULL, ARCHIVE_UNTIL, or DENY — and fails closed if the provider is unavailable.

🗂 Handling Archive Cutoffs (Harder Than It Looks)

Example:

User subscribes Jan 1
Expires Jan 31
Re-subscribes Feb 20
Admin policy: 7-day backfill

Readable windows become:

(-∞, Jan 31]
[Feb 13, now]

That middle 13-day gap? Hidden.

This required time-window enforcement at the query layer — applied consistently to REST, Realtime, and Signed Media URL issuance. Security invariants must be consistent everywhere.

🔐 Media Security — Best-Effort No-Download

For premium investment content:

All files stored privately
Signed URLs with TTL ≤ 5 minutes
Scope-bound to user + channel + post
Issued only after access check

signed_url(user_id, channel_id, post_id, exp)

We don't pretend screenshots can be stopped — but we prevent casual link sharing.

⚙️ Concurrency — Why `MAX(seq)+1` Is Forbidden

Never allocate sequence numbers in application code.

❌ Wrong:

SELECT MAX(seq) FROM posts WHERE channel_id=1;
-- then +1 in code

✅ Correct — atomic counter table:

INSERT INTO channel_seq_counter (channel_id, next_seq)
VALUES ($1, 2)
ON CONFLICT (channel_id)
DO UPDATE SET next_seq = channel_seq_counter.next_seq + 1
RETURNING next_seq - 1;

Sequence allocation and post insert happen in the same transaction. No duplicates. No race conditions.

🔁 Idempotent Publishing — 24h Replay Protection

Admins double-click publish. Networks retry. We implemented:

Idempotency-Key header
Unique scope: actor + endpoint + channel
24h TTL
Same key + same payload → replay original response
Same key + different payload → 409 Conflict

Atomic rule: post row + outbox row + idempotency row must commit in the same transaction. No partial success allowed.

📡 Realtime — IDs Only, Never Content

WebSocket model:

JWT handshake
Authorization on every subscription
On publish → send delta:

{
  "channel_id": 1,
  "seq": 145,
  "post_id": 9001
}

Client must call REST for full post content.

Why? Access can change between delta and fetch. REST re-checks entitlement. This prevents data leaks.

🧱 Reliability Layer

We added:

Transactional outbox pattern
At-least-once event publishing
Deduplication via event_dedupe_key
Tombstone deletes (cursor-safe)
RPO 15m / RTO 2h
Baseline SLO: 99.9% API availability

Deleted posts remain in sequence:

{
  "id": 123,
  "seq": 456,
  "is_deleted": true,
  "body_text": null
}

This preserves pagination integrity.

🧠 Product Decisions That Shaped Architecture

Broadcast must stay clean → no replies allowed
Premium users may retain archive-only access
Re-subscribe should not expose full historical content
Access must fail closed
Communication must remain independent from monetization logic

Clean boundaries reduce long-term complexity.

🧩 Core Tables (Simplified)

Table	Purpose
`channels`	Broadcast channel definitions
`posts`	Channel messages (store-once)
`post_attachments`	Secure media references
`forums`	Discussion rooms
`topics`	Forum threads
`messages`	Thread replies
`visibility_rules`	Access window definitions
`idempotency_keys`	Replay protection
`outbox_events`	Reliable event publishing
`*_seq_counter`	Atomic sequence allocation

Everything supports deterministic ordering, access-window enforcement, and production safety.

🏁 Final Thoughts

Building a Telegram-style system is easy.

Building one that supports paid archive cutoffs, re-subscribe backfill logic, secure premium media, concurrency-safe publish, audit logging, and horizontal scalability — is not trivial.

Key lessons:

Separate broadcast from discussion
Separate communication from monetization
Enforce access at every boundary
Make ordering deterministic
Treat reliability as first-class

If you're building paid communities, investment signal platforms, course-based broadcast systems, or subscription media platforms — I'd love to exchange notes. Drop a comment below 👇

class-validator Cheatsheet: Useful Decorators and NestJS Validation Patterns (2025)

Subhash Adhikari — Mon, 04 Aug 2025 21:03:29 +0000

This is your complete reference for all major class-validator decorators, their usage, value types, and integration patterns. Bookmark this if you’re working with DTOs in NestJS or doing input validation in any TypeScript project.

🚀 Install First

npm install class-validator class-transformer

✅ Basic Usage Pattern

import { IsEmail, MinLength, validate } from 'class-validator';

class LoginDto {
  @IsEmail()
  email: string;

  @MinLength(6)
  password: string;
}

const login = new LoginDto();
login.email = 'invalid';
login.password = '123';

const errors = await validate(login);

🧾 Core Decorators Reference

Decorator	Purpose	Accepted Type(s)
`@IsString()`	Must be a string	`string`
`@IsBoolean()`	Must be boolean	`boolean`
`@IsInt()`	Must be an integer	`number`
`@IsNumber()`	Any number (int or float)	`number`
`@IsEmail()`	Valid email address	`string`
`@IsDate()`	Must be a Date instance	`Date`
`@IsOptional()`	Skip validation if undefined/null	`any`
`@IsNotEmpty()`	Not empty (works with string, array)	`string`, `array`
`@IsDefined()`	Value must be present (not undefined)	`any`

🔢 Number Validations

Decorator	Description
`@Min(value)`	Minimum number allowed
`@Max(value)`	Maximum number allowed
`@IsPositive()`	Must be positive
`@IsNegative()`	Must be negative

🔠 String Validations

Decorator	Description
`@MinLength(n)`	Minimum string length
`@MaxLength(n)`	Maximum string length
`@Matches(regex)`	Must match regex pattern
`@IsAlpha()`	Only letters
`@IsAlphanumeric()`	Letters and numbers only
`@IsPhoneNumber()`	Must be a valid phone number
`@IsUrl()`	Must be a valid URL

🔁 Array Validations

Decorator	Description
`@IsArray()`	Must be an array
`@ArrayMinSize(n)`	Minimum length of array
`@ArrayMaxSize(n)`	Maximum length of array
`@ArrayNotEmpty()`	Must not be empty
`@IsInt({ each: true })`	Validates each element (works with many)

🔘 Enum & Object Validations

enum Role { USER = 'user', ADMIN = 'admin' }

@IsEnum(Role)
role: Role;

@ValidateNested()
@Type(() => Profile)
profile: Profile;

@ValidateNested() is required for nested objects
Must be combined with @Type(() => ClassName) from class-transformer

⚖️ Conditional Validation

@ValidateIf(o => o.isAdult)
@IsString()
licenseNumber: string;

Use @ValidateIf() to apply a rule conditionally based on other values.

🛠 Custom Validators

@ValidatorConstraint({ name: 'IsStrongPassword', async: false })
class IsStrongPassword implements ValidatorConstraintInterface {
  validate(value: string) {
    return typeof value === 'string' && value.length >= 8 && /[A-Z]/.test(value);
  }

  defaultMessage() {
    return 'Password must be at least 8 chars and include an uppercase letter.';
  }
}

Use it like this:

@Validate(IsStrongPassword)
password: string;

⚙️ NestJS Global Integration

// main.ts
app.useGlobalPipes(new ValidationPipe({
  whitelist: true,
  forbidNonWhitelisted: true,
  transform: true,
  transformOptions: { enableImplicitConversion: true }
}));

🧠 Common Mistakes to Avoid

❌ Forgetting @Type(): Nested validation won’t work without it
❌ Validating plain objects: Use plainToInstance() from class-transformer
❌ Wrong order of decorators: Execution is bottom-to-top, so arrange carefully

📦 Pro Tips

Combine @IsOptional() with other validators to skip when empty
Use { each: true } to apply decorators to every array element
Custom validators = reusable logic for business rules
Enable stopAtFirstError in ValidationPipe to fail fast

🔗 Resources

✅ Use this cheatsheet in every TypeScript API project using DTOs. Fast, reliable, and easy to maintain.

Mastering Validation in TypeScript with class-validator – A Complete Beginner's Guide

Subhash Adhikari — Sat, 02 Aug 2025 15:50:43 +0000

Learn how to validate user input in TypeScript and NestJS using class-validator. This in-depth tutorial covers everything from basic usage to advanced decorators, real-world use cases, and integration with NestJS — all optimized for clean code, security, and SEO.

📌 Table of Contents

What is class-validator?
Why Input Validation Matters
Installation
Basic Example: Email and Password Validation
Popular Validation Decorators
Advanced Validation: Arrays, Enums, Dates
Nested Object Validation
Conditional Validation with @ValidateIf
Custom Validators
Full Integration with NestJS
Common Pitfalls and Mistakes
Final Takeaways
Connect with Me

🧠 What is `class-validator`?

class-validator is a powerful library that allows you to use decorators to validate TypeScript class properties. It's most commonly used with frameworks like NestJS or in pure Node.js apps to enforce runtime validation.

❗ Why Input Validation Matters

🔐 Prevents invalid or malicious data
🧼 Ensures clean, predictable input
📉 Reduces bugs in business logic
🔧 Improves API documentation and usability

⚙️ Installation

Install it along with class-transformer:

npm install class-validator class-transformer

🧪 Basic Example: Email and Password Validation

import { IsEmail, MinLength } from 'class-validator';

export class CreateUserDto {
  @IsEmail()
  email: string;

  @MinLength(6)
  password: string;
}

import { validate } from 'class-validator';

const user = new CreateUserDto();
user.email = 'wrong-format';
user.password = '123';

const errors = await validate(user);
console.log(errors); // -> array of error messages

📋 Popular Validation Decorators

Decorator	Use Case
`@IsString()`	Ensure field is a string
`@IsEmail()`	Validate email format
`@IsInt()`	Ensure field is an integer
`@Min()` / `@Max()`	Number boundaries
`@MinLength()` / `@MaxLength()`	String length
`@IsBoolean()`	Must be true/false
`@IsOptional()`	Skips validation if not present

💡 Advanced Validation: Arrays, Enums, Dates

Validate Arrays

@IsArray()
@IsInt({ each: true })
scores: number[];

Validate Enums

enum Role { USER = 'user', ADMIN = 'admin' }

@IsEnum(Role)
role: Role;

Validate Dates

@IsDate()
@MinDate(new Date())
joinDate: Date;

🧱 Nested Object Validation

class Profile {
  @IsString()
  bio: string;
}

class User {
  @ValidateNested()
  @Type(() => Profile)
  profile: Profile;
}

Always include @Type() from class-transformer, or validation will silently fail.

⚖️ Conditional Validation with `@ValidateIf`

@ValidateIf(o => o.age > 18)
@IsString()
licenseNumber: string;

This only validates licenseNumber if age > 18.

🔧 Custom Validators

@ValidatorConstraint({ name: 'IsStrongPassword', async: false })
class IsStrongPassword implements ValidatorConstraintInterface {
  validate(value: string) {
    return value.length >= 8 && /[A-Z]/.test(value);
  }

  defaultMessage() {
    return 'Password must have at least 8 characters and one uppercase letter.';
  }
}

Use it like this:

@Validate(IsStrongPassword)
password: string;

🚀 Full Integration with NestJS

`main.ts` Setup

app.useGlobalPipes(
  new ValidationPipe({
    whitelist: true,
    forbidNonWhitelisted: true,
    transform: true,
    transformOptions: {
      enableImplicitConversion: true
    }
  })
);

Sample DTO and Controller

// create-user.dto.ts
export class CreateUserDto {
  @IsEmail()
  email: string;

  @MinLength(6)
  password: string;

  @IsOptional()
  @IsInt()
  @Min(18)
  age?: number;
}

// users.controller.ts
@Post()
create(@Body() dto: CreateUserDto) {
  return this.userService.create(dto);
}

NestJS will automatically:

Validate the body
Convert string to numbers if needed
Throw 400 Bad Request on validation failure

❌ Common Pitfalls and Mistakes

1. Forgetting `@Type()` in Nested DTOs

@ValidateNested()
profile: Profile; // ❌ Will not validate

// ✅ Fix:
@ValidateNested()
@Type(() => Profile)
profile: Profile;

2. Wrong Order of Decorators

@IsEmail()
@IsNotEmpty()
email: string;
// Runs bottom-up: IsNotEmpty first, then IsEmail

Always order carefully if decorators depend on each other.

3. Not Using `plainToInstance()`

const user = plainToInstance(CreateUserDto, req.body);
await validate(user);

Without this, validation may silently fail if using plain JS objects.

✅ Final Takeaways

Use @IsOptional() when fields aren't required
Always use @Type() in nested objects
Use ValidationPipe in NestJS for automatic validation
Validate arrays with { each: true }
Use custom validators for complex business rules

🔄 What About Zod?

While this guide focuses on class-validator, many developers also consider zod for validating data in TypeScript. If you're wondering how it compares, here’s a quick breakdown to help you choose the best tool for your needs:

🥊 class-validator vs Zod: Which Should You Use?

Feature / Use Case	✅ `class-validator`	🔥 `zod`
TypeScript Decorator Support	✅ Yes (`@IsEmail()`, `@MinLength()`, etc.)	❌ No decorators — schema-based only
OOP / Class-based structure	✅ Excellent fit (DTOs, NestJS)	❌ Functional only
Functional/Composable validation	😐 Limited	✅ Designed for functional composition
Schema inference from types	❌ Manual type declarations	✅ `z.infer<typeof Schema>` supported
Runtime type validation	✅ Yes	✅ Yes
Integration with NestJS	✅ Native via `ValidationPipe`	❌ Requires custom adapters or wrappers
Performance	⚠️ Slightly heavier (uses decorators + reflection)	⚡ Very fast and lightweight
Custom validators	✅ Class-based rules	✅ Function-based rules
Serialization support	✅ via `class-transformer`	❌ Not included
Learning curve	😐 Slightly steeper (due to decorators)	✅ Beginner-friendly

✅ When to Use `class-validator`

You're using NestJS
You prefer OOP and decorators
You need class-transformer for serialization
Your architecture uses DTO classes

⚡ When to Use `Zod`

You're building with functional programming style
You're using tRPC, Express, or Fastify
You want fast runtime validation and type inference
You prefer schema-based design

🧠 Final Word

Both libraries are excellent. Your choice depends on:

Your framework (NestJS vs Express/tRPC)
Your programming style (OOP vs functional)
Your team’s preference for decorators vs schemas

If you prefer decorators and structured classes, go with class-validator.

If you prefer schema inference and functional composition, go with zod.

🙌 Connect with Me

If this helped you, please:

📚 Official Repo: github.com/typestack/class-validator
📬 Share your thoughts in comments
🔗 Connect with me on LinkedIn

Want a quick reference? I’m posting a class-validator cheatsheet next! Follow me to stay updated.