DEV Community: amir taherkhani

Redis Pub/Sub vs Redis Streams

amir taherkhani — Mon, 22 Dec 2025 15:37:10 +0000

Redis Pub/Sub vs Redis Streams — A Practical Guide to Choosing the Right Messaging Model

Redis provides multiple ways to handle messaging between services — with Pub/Sub and Streams being the two key built-in options. Although they may look similar at first glance, they solve very different problems. Choosing the wrong one can lead to message loss, scalability issues, or unnecessary complexity.

This article expands on the original discussion and adds practical guidance, architectural reasoning, and real-world decision rules for production systems.

What Are Redis Pub/Sub and Redis Streams?

Redis Pub/Sub — Fire-and-Forget Messaging

Redis Pub/Sub implements a classic publish / subscribe pattern:

Publishers send messages to channels
Subscribers receive messages only if they are connected at publish time

There is no message storage, retry, or replay mechanism.

Key Characteristics

Feature	Pub/Sub
Message persistence	❌ No
Delivery guarantee	At-most-once
Offline consumption	❌ No
Consumer groups	❌ No
Ordering	Best effort
Complexity	Very low

When Pub/Sub Makes Sense

Live UI updates (dashboards, live cursors, presence)
Chat systems where missed messages are acceptable
Broadcasting system state to connected clients

Core Limitation

If a subscriber is disconnected, slow, or crashes, the message is lost forever.

Redis Streams — Durable Event Logs

Redis Streams introduce a persistent, append-only log designed for reliable event processing.

Messages are stored in Redis and consumed at the consumer’s own pace.

Core Concepts

Stream – ordered log of messages
Message ID – monotonic unique identifier
Consumer Group – coordinated consumption across multiple consumers
ACK – confirms successful processing
PEL (Pending Entries List) – tracks unacknowledged messages

Key Characteristics

Feature	Streams
Message persistence	✔ Yes
Delivery guarantee	At-least-once
Offline consumption	✔ Yes
Consumer groups	✔ Yes
Replay	✔ Yes
Complexity	Medium–High

When Streams Make Sense

Job queues and background workers
Event-driven microservices
Audit logs and event sourcing
Systems requiring recovery and retries

Side-by-Side Comparison

Aspect	Pub/Sub	Streams
Persistence	No	Yes
Replay	No	Yes
ACK support	No	Yes
Consumer groups	No	Yes
Failure recovery	No	Yes
Latency	Very low	Low–medium
Operational complexity	Minimal	Moderate

How Pub/Sub Works Internally

Subscriber connects and subscribes to a channel
Publisher publishes a message
Redis immediately pushes the message to all active subscribers

If the subscriber is not connected at that moment, the message is dropped.

There is no back-pressure handling and no message history.

How Redis Streams Work Internally

Producer appends messages using XADD
Redis stores messages with unique IDs
Consumers read messages using XREAD or XREADGROUP
Consumers acknowledge processing with XACK
Unacknowledged messages remain in the PEL for recovery

Streams behave similarly to Kafka or SQS, but fully embedded in Redis.

Delivery Guarantees Explained

Pub/Sub — At-Most-Once

Messages are delivered zero or one time
No retry, no confirmation
Best suited for non-critical data

Streams — At-Least-Once

Messages are persisted
Processing can be retried
Consumers must handle potential duplicates

Scaling Considerations

Pub/Sub

Extremely fast
Minimal memory overhead
Fan-out cost increases with subscriber count

Streams

Higher memory usage
Consumer groups distribute load
Supports horizontal scaling and fault tolerance

Decision Rules (Use This in Real Projects)

Scenario	Recommended Choice
Live notifications only	Pub/Sub
Business-critical processing	Streams
UI events	Pub/Sub
Distributed workers	Streams
Need replay or recovery	Streams
Minimal latency, no history	Pub/Sub

Real-World Example

Notifications

Only online users matter → Pub/Sub
Every user must receive the message → Streams

Order Processing Pipeline

Inventory, billing, shipping coordination → Streams

Common Mistakes

Using Pub/Sub as a job queue ❌
Expecting durability from Pub/Sub ❌
Ignoring duplicate processing in Streams ❌
Never trimming old stream entries ❌

Summary

Redis offers two messaging paradigms:

Pub/Sub — simple, fast, ephemeral
Streams — durable, reliable, replayable

Choose based on delivery guarantees, failure tolerance, and system complexity, not convenience.

Rule of thumb:

Message loss acceptable → Pub/Sub
Message loss unacceptable → Streams

NestJS Design Patterns

amir taherkhani — Sun, 11 May 2025 11:22:10 +0000

Analytical Perspectives and Strategic Applications for Scalable Architectures

This document serves as an advanced reference for software architects and backend engineers utilizing the NestJS framework to design robust, scalable, and maintainable systems. It systematically explores a broad spectrum of software design patterns, each tailored for application within the context of NestJS. With a focus on theoretical foundations, practical use cases, scalability considerations, and illustrative code examples, this guide bridges conceptual architecture with real-world development practices.

1. Modular Architecture Pattern

Application Context: Facilitates the decomposition of a system into discrete, feature-centric modules, each encapsulating domain logic and dependencies.
Scalability Assessment: Highly effective for scaling large codebases by promoting bounded contexts and autonomous development cycles.

Use Cases: Domain-driven design, feature toggling, microservice-aligned code separation.

2. Dependency Injection (DI) Pattern

Application Context: Enables decoupled class instantiation and promotes inversion of control, enhancing flexibility in managing dependencies.
Scalability Assessment: Foundational to scalable NestJS systems; facilitates composability and unit testing.

Use Cases: Dynamic configuration loading, multi-tenant environments, and mocking in unit tests.

3. Controller-Service-Repository Pattern

Application Context: Establishes a hierarchical structure for separating HTTP handling, business logic, and data access.
Scalability Assessment: Promotes maintainability, reusability, and abstraction—vital in large-scale applications.

Use Cases: RESTful APIs, layered services, structured domain-driven implementations.

4. Repository Pattern

Application Context: Abstracts data layer interactions, allowing substitution of storage backends without impacting business logic.
Scalability Assessment: Essential for persistence-agnostic design; simplifies testing and data access refactoring.

Use Cases: ORM abstraction, mocking data sources, transitioning between databases.

5. Factory Pattern

Application Context: Constructs instances dynamically based on runtime criteria or configurations.
Scalability Assessment: Highly beneficial in multi-environment setups or pluggable architectures.

Use Cases: Logging configuration, dependency instantiation based on context, strategy selectors.

6. Strategy Pattern

Application Context: Encapsulates algorithmic behavior and enables dynamic substitution without modifying consuming logic.
Scalability Assessment: Supports extensibility and modular business logic injection.

Use Cases: Authentication flows, payment gateway integrations, behavior-driven services.

7. Builder Pattern

Application Context: Constructs complex data objects or query parameters incrementally and fluently.
Scalability Assessment: Enhances readability and maintainability of configuration logic.

Use Cases: Dynamic query generation, DTO assembly, chained configuration utilities.

8. Observer Pattern

Application Context: Facilitates loosely coupled event-driven communication between disparate modules.
Scalability Assessment: Pivotal in reactive and event-oriented architectures.

Use Cases: Domain event propagation, audit logging, notification broadcasting.

9. Middleware Pattern

Application Context: Implements cross-cutting concerns at the request-processing pipeline stage.
Scalability Assessment: Suitable for centralizing security and operational layers.

Use Cases: Authentication, request logging, metrics injection.

10. Interceptor Pattern

Application Context: Enables interception and transformation of method responses and error flows.
Scalability Assessment: Ideal for implementing AOP-like constructs and reusable business rules.

Use Cases: Response shaping, exception wrapping, conditional caching.

11. Adapter Pattern

Application Context: Translates external APIs or systems into interfaces that conform to the application's expectations.
Scalability Assessment: Indispensable for isolating infrastructure changes from domain logic.

Use Cases: External payment services, cloud storage APIs, third-party logging.

12. Proxy Pattern

Application Context: Intercepts method calls to augment behavior transparently.
Scalability Assessment: Valuable in performance tuning and service orchestration.

Use Cases: Rate limiting, lazy loading, distributed cache facades.

13. CQRS Pattern (Command Query Responsibility Segregation)

Application Context: Segregates the responsibilities of data mutation and data retrieval.
Scalability Assessment: Enables optimization of read/write models, crucial for high-throughput systems.

Use Cases: Financial transactions, e-commerce systems, audit-tracked updates.

14. Event Bus (Pub/Sub) Pattern

Application Context: Disseminates domain events to loosely coupled subscribers asynchronously.
Scalability Assessment: Empowers event-driven and eventually consistent distributed systems.

Use Cases: Workflow orchestration, integration events, reactive microservices.

15. Singleton Pattern

Application Context: Guarantees a single shared instance across the application lifecycle.
Scalability Assessment: Effective for shared configurations and resource pools.

Use Cases: Configuration services, logging services, environment-sensitive utilities.

16. Hexagonal Architecture (Ports and Adapters)

Application Context: Organizes systems into inbound/outbound interfaces surrounding a core domain model.
Scalability Assessment: Highly adaptable for long-term evolution and infrastructure independence.

Use Cases: Domain-driven applications, API and CLI adapters, decoupling infrastructure dependencies.

17. Bridge Pattern

Application Context: Decouples abstraction from its implementation, allowing both to evolve independently.
Scalability Assessment: Useful in building extensible service bridges with multiple layers of variation.

Use Cases: Logging frameworks, external storage abstractions, service mediators.

18. Decorator Pattern

Application Context: Augments class behavior dynamically via metadata and reflection.
Scalability Assessment: Core to NestJS metaprogramming; highly composable.

Use Cases: Guards, interceptors, pipes, dependency tagging.

19. Template Method Pattern

Application Context: Defines skeleton workflows with customizable sub-steps.
Scalability Assessment: Facilitates uniform operations while permitting domain-specific overrides.

Use Cases: Job pipelines, ETL routines, test scenario execution.

20. Chain of Responsibility Pattern

Application Context: Processes a request through a sequence of handlers.
Scalability Assessment: Ideal for modular middleware pipelines and dynamic command resolution.

Use Cases: Authorization stacks, validation layers, dynamic event routers.

21. Command Pattern

Application Context: Encapsulates operations as discrete objects, enabling queuing, logging, and replayability.
Scalability Assessment: Well-suited for task-oriented and distributed command processing systems.

Use Cases: CQRS command dispatchers, job queues, undo/redo stacks.

Example Structures and Usage

1. Modular Architecture Pattern

Example:

// users.module.ts
@Module({
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService],
})
export class UsersModule {}

2. Dependency Injection (DI) Pattern

Example:

@Injectable()
export class AuthService {
  constructor(private readonly usersService: UsersService) {}
}

3. Controller-Service-Repository Pattern

Example:

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

4. Repository Pattern

Example:

@Injectable()
export class UserRepository {
  constructor(private readonly prisma: PrismaService) {}

  async findById(id: string): Promise<User | null> {
    return this.prisma.user.findUnique({ where: { id } });
  }

  async create(data: CreateUserDto): Promise<User> {
    return this.prisma.user.create({ data });
  }
}

5. Factory Pattern

Example:

@Module({
  providers: [
    {
      provide: 'ASYNC_LOGGER',
      useFactory: async (configService: ConfigService) => {
        return new LoggerService(configService.get('LOG_LEVEL'));
      },
      inject: [ConfigService],
    },
  ],
})
export class LoggingModule {}

6. Strategy Pattern

Example:

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(private configService: ConfigService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: configService.get('JWT_SECRET'),
    });
  }
}

7. Builder Pattern

Example:

const query = new UserQueryBuilder()
  .withAge(30)
  .withStatus('active')
  .build();

8. Observer Pattern

Example:

@OnEvent('user.created')
handleUserCreated(user: User) {
  this.mailService.sendWelcomeEmail(user.email);
}

9. Middleware Pattern

Example:

@Injectable()
export class AuthMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: Function) {
    console.log('Checking auth...');
    next();
  }
}

10. Interceptor Pattern

Example:

@Injectable()
export class ResponseInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    return next.handle().pipe(map(data => ({ success: true, data })));
  }
}

11. Adapter Pattern

Example:

export class StripePaymentAdapter implements PaymentInterface {
  charge(amount: number) {
    return this.stripe.charge({ amount });
  }
}

12. Proxy Pattern

Example:

@Injectable()
export class CachingProxy {
  constructor(private readonly redisService: RedisService) {}

  async getData(key: string, fallback: () => Promise<any>) {
    const cached = await this.redisService.get(key);
    if (cached) return JSON.parse(cached);
    const result = await fallback();
    await this.redisService.set(key, JSON.stringify(result));
    return result;
  }
}

13. CQRS Pattern (Command Query Responsibility Segregation)

Example:

export class CreateUserCommand {
  constructor(public readonly username: string) {}
}

@CommandHandler(CreateUserCommand)
export class CreateUserHandler implements ICommandHandler<CreateUserCommand> {
  async execute(command: CreateUserCommand) {
    // handle logic
  }
}

14. Event Bus (Pub/Sub) Pattern

Example:

export class UserCreatedEvent {
  constructor(public readonly userId: string) {}
}

@EventsHandler(UserCreatedEvent)
export class SendEmailOnUserCreated {
  handle(event: UserCreatedEvent) {
    // send email logic
  }
}

15. Singleton Pattern

Example:

@Injectable()
export class ConfigService {
  private readonly config = new Map();

  get(key: string): string {
    return this.config.get(key);
  }
}

16. Hexagonal Architecture (Ports and Adapters)

Example:

// Port interface
export interface NotificationPort {
  send(email: string, message: string): Promise<void>;
}

// Adapter implementation
@Injectable()
export class EmailService implements NotificationPort {
  async send(email: string, message: string): Promise<void> {
    // send email
  }
}

17. Bridge Pattern

Example:

abstract class Logger {
  constructor(protected transport: Transport) {}
  abstract log(message: string): void;
}

class FileLogger extends Logger {
  log(message: string) {
    this.transport.writeToFile(message);
  }
}

18. Decorator Pattern

Example:

@UseGuards(AuthGuard)
@Get('profile')
getProfile(@Request() req) {
  return req.user;
}

19. Template Method Pattern

Example:

abstract class ReportGenerator {
  generate() {
    this.fetchData();
    this.formatData();
    this.export();
  }

  abstract fetchData(): void;
  abstract formatData(): void;
  export() {
    console.log('Exporting report...');
  }
}

20. Chain of Responsibility Pattern

Example:

@Injectable()
export class AuthHandler {
  setNext(handler: AuthHandler): AuthHandler {
    this.nextHandler = handler;
    return handler;
  }

  handle(request: any) {
    if (this.canHandle(request)) {
      return this.process(request);
    } else if (this.nextHandler) {
      return this.nextHandler.handle(request);
    }
  }
}

21. Command Pattern

Example:

export class DeleteUserCommand {
  constructor(public readonly userId: string) {}
}

@CommandHandler(DeleteUserCommand)
export class DeleteUserHandler implements ICommandHandler<DeleteUserCommand> {
  async execute(command: DeleteUserCommand) {
    // delete user logic
  }
}

Design Pattern Popularity Chart

Modular Architecture         ██████████████████████████████████████ 95
Dependency Injection         ███████████████████████████████████    90
Controller-Service-Repo      ████████████████████████████████       88
CQRS                         █████████████████████████████          85
Hexagonal Architecture       ██████████████████████████             80
Observer                     █████████████████████████              78
Strategy                     ████████████████████████               75
Repository                   █████████████████████                  70
Factory                      ████████████████████                   68
Event Bus                    ███████████████████                    65

Design Pattern Categories and Grouping

Category	Design Patterns
Architectural	- Modular Architecture - Hexagonal Architecture
Structural	- Controller-Service-Repository - Repository - Adapter - Bridge - Decorator
Creational	- Factory - Singleton - Builder
Behavioral	- Strategy - Observer - Interceptor - Middleware - Chain of Responsibility - Command - Template Method - Proxy
Distributed/Event	- Event Bus - CQRS
Cross-Cutting	- Dependency Injection

Summary Table

Pattern	Representative Context
Modular	Feature separation
Dependency Injection	Configurable service instantiation
Controller-Service-Repo	HTTP, logic, and persistence layers
Factory	Dynamic provider instantiation
Strategy	Behavior switching
Builder	Complex query generation
Observer	Event broadcast
Adapter	External integration normalization
Proxy	Caching, throttling
Singleton	Shared runtime service
Interceptor	Response transformation
Middleware	Request preprocessing
CQRS / Command / Event	Separated query/command processing
Decorator	Class-level metadata annotation
Chain of Responsibility	Sequential handler pipeline
Hexagonal	Core-domain isolation

Conclusion:
The NestJS framework inherently supports various architectural and design patterns that enable scalable, modular, and testable system construction. Mastery and strategic application of these patterns are vital in addressing complexity, maintaining separation of concerns, and facilitating agile development cycles across distributed and enterprise-grade software platforms.

DEV Community: amir taherkhani

Redis Pub/Sub vs Redis Streams

Redis Pub/Sub vs Redis Streams — A Practical Guide to Choosing the Right Messaging Model

What Are Redis Pub/Sub and Redis Streams?

Redis Pub/Sub — Fire-and-Forget Messaging

Key Characteristics

When Pub/Sub Makes Sense

Core Limitation

Redis Streams — Durable Event Logs

Core Concepts

Key Characteristics

When Streams Make Sense

Side-by-Side Comparison

How Pub/Sub Works Internally

How Redis Streams Work Internally

Delivery Guarantees Explained

Pub/Sub — At-Most-Once

Streams — At-Least-Once

Scaling Considerations

Pub/Sub

Streams

Decision Rules (Use This in Real Projects)

Real-World Example

Notifications

Order Processing Pipeline

Common Mistakes

Summary

Further Reading

NestJS Design Patterns

1. Modular Architecture Pattern

2. Dependency Injection (DI) Pattern

3. Controller-Service-Repository Pattern

4. Repository Pattern

5. Factory Pattern

6. Strategy Pattern

7. Builder Pattern

8. Observer Pattern

9. Middleware Pattern

10. Interceptor Pattern

11. Adapter Pattern

12. Proxy Pattern

13. CQRS Pattern (Command Query Responsibility Segregation)

14. Event Bus (Pub/Sub) Pattern

15. Singleton Pattern

16. Hexagonal Architecture (Ports and Adapters)

17. Bridge Pattern

18. Decorator Pattern

19. Template Method Pattern

20. Chain of Responsibility Pattern

21. Command Pattern

Example Structures and Usage

1. Modular Architecture Pattern

2. Dependency Injection (DI) Pattern

3. Controller-Service-Repository Pattern

4. Repository Pattern

5. Factory Pattern

6. Strategy Pattern

7. Builder Pattern

8. Observer Pattern

9. Middleware Pattern

10. Interceptor Pattern

11. Adapter Pattern

12. Proxy Pattern

13. CQRS Pattern (Command Query Responsibility Segregation)

14. Event Bus (Pub/Sub) Pattern

15. Singleton Pattern

16. Hexagonal Architecture (Ports and Adapters)

17. Bridge Pattern

18. Decorator Pattern

19. Template Method Pattern

20. Chain of Responsibility Pattern

21. Command Pattern

Design Pattern Popularity Chart

Design Pattern Categories and Grouping

Summary Table