System Design Document

for

Blink Chat–A Real Time Web Based

Messaging Platform

Abhishek Gaonkar
2317065
MCA
St Aloysius Institute of Management and Information Technology(AIMIT)
Mangalore
20/05/2025

Under the guidance of

Mrs. Annapoorna Shetty
Assistant Proffessor
St Aloysius Institute of Management and Information Technology(AIMIT)
Mangaluru, Karnataka

Submitted to

ALOYSIUS INSTITUTE OF MANAGEMENT AND INFORMATION

TECHNOLOGY (AIMIT)
ST ALOYSIUS COLLEGE (AUTONOMOUS)
MANGALORE, KARNATAKA
1. Introduction
1.1 Purpose

The purpose of this Software Design Document (SDD) is to present a clear, detailed blueprint
for implementing Blink_Chat, guiding developers from the SRS to working code. It describes
the overall system architecture, individual software components, interfaces, and data
structures needed for construction. Each requirement defined in the SRS is mapped to one or
more design entities herein, ensuring full traceability. This document is intended for software
architects, developers, testers, and project evaluators who will implement, verify, and maintain
the system. By consolidating design decisions in one place, it minimizes ambiguity, promotes
consistency, and speeds up development. It also serves as a reference for future
enhancements or troubleshooting of Blink_Chat.

1.2 Scope
This SDD covers the end-to-end design of the Blink_Chat platform, from user interface
components through backend services to database schemas and external integrations. It
builds directly on the SRS, detailing how each functional requirement—real-time messaging,
profile management, status updates, media handling—is realized in software. The scope
includes decomposition of the system into modules, description of their interactions, data
flows, and deployment considerations. It does not cover the physical network infrastructure or
cloud provisioning steps, which are handled separately by DevOps documentation. Future
extensions (e.g., video calling, chatbots) are noted but out of scope for this version. This SDD
ensures the development team has everything needed to proceed to coding and testing.

1.3 Definitions, Acronyms and Abbreviations

•Blink_Chat: The project name, a browser-based real-time messaging platform.
•Socket.IO: Library enabling real-time bidirectional communication over WebSockets.
•MERN: Acronym for MongoDB, Express.js, React.js, Node.js—the chosen tech stack.
•Cloudinary: Cloud media management service for storing and serving images.
•API: Application Programming Interface, here referring to REST endpoints and WebSocket
events.
•UI: User Interface, the React-based front end of Blink_Chat.
•SRS: Software Requirements Specification, the precursor document defining “what” the
system must do.
•SDD: Software Design Document, this document, describing “how” the system is built.
2. References
1. Socket.IO Documentation – Details on event names, connection lifecycle, and
configuration options.
2. React.js Official Guides – Best practices for component design, state management,
and hooks.
3. MongoDB Atlas Documentation – Guidelines for collections, indexes, and performance
tuning in MongoDB.
4. Cloudinary Developer Docs – API reference for secure upload, transformation, and
delivery of media.
5. Express.js API Reference – Routing, middleware, error-handling patterns for Node.js
servers.
6. Figma Design System – UI mockups, component variants, and styling guidelines
(TailwindCSS).
7. W3C Web Standards – Accessibility (WCAG), HTML5, CSS3 and WebSocket protocol
specifications.
8. Bcrypt.js – Library for hashing and verifying user passwords in Node.js.

3. Attributes of Design Entities

3.1 Identification
Each design entity has a unique identifier, for example:
• AuthController
• ChatService
• UserSchema
• MessageComponent
No two entities share the same name, preventing confusion during development and testing.

3.2 Type
Entities are categorized by their nature, such as:
• Module (e.g., AuthModule)
• Service (e.g., SocketService)
• Component (React UI elements)
• Data Schema (Mongoose models)
• Utility (e.g., EncryptionUtils)
3.3 Purpose
Each entity exists to satisfy one or more SRS requirements. For instance, ChatService
implements real-time message routing (FR-1 through FR-8). ProfileController enables profile
updates and image uploads, meeting requirements for secure media handling and user
personalization.

3.4 Function
This attribute specifies input-to-output transformations.
•MessageComponent takes user-entered text and emits a send_message event.
•AuthService validates credentials and returns JWT tokens.
•CloudinaryAdapter receives binary image data and returns an accessible URL.

3.5 Subordinates
Composite entities list their children, for example:
• ChatModule includes MessageInput, MessageList, NotificationBanner.
• DatabaseLayer comprises UserSchema, MessageSchema, ConnectionPool.

3.6 Dependencies
Entities declare interactions with others:
•ChatService depends on SocketService for real-time transport and on MessageRepository
for persistence.
•AuthController relies on EncryptionUtils and UserRepository.

3.7 Interface
Defines how external or internal clients interact:
•POST /login expects { username, password } and returns { token } or error codes.
•WebSocket event update_status expects { userId, status } and broadcasts to all contacts.

3.8 Resources
Specifies required external resources:
• CPU and memory budgets for handling 100+ concurrent sockets.
• MongoDB Atlas cluster connections.
• Cloudinary API key and bandwidth.
3.9 Processing
Describes core algorithms and control flow:
• Socket reconnection policy: retry every 2 seconds, up to 5 attempts.
• Message queueing logic to buffer offline deliveries.
• Validation pipeline for incoming profile images.

3.10 Data
Defines data structures, formats, and constraints:
•User document: { _id, username: String(3–20), passwordHash, profileUrl }
•Message document: { _id, from: ObjectId, to: ObjectId, text: String, timestamp: Date }
•Acceptable image formats: JPEG, PNG; max size: 2 MB.

Database table: user

Attribute Datatype Constraint

_id varchar Primary key

email varchar NOT NULL

fullname varchar NOT NULL

profile picture Image NOT NULL

createdAt Date NOT NULL

updatedAt Date NOT NULL

Messages
Attribute Datatype Constraint

_id varchar Primary key

 senderId varchar NOT NULL

receiverId varchar NOT NULL

text string NOT NULL

createdAt date NOT NULL

updatedAt date NOT NULL

4. Decomposition Description

4.1 General Structure

The system divides into four primary subsystems:
1. Frontend: React.js + TailwindCSS components for UI.
2. Backend: Node.js + Express.js REST API and Socket.IO server.
3. Database: MongoDB for persistence of users, messages, and status logs.
4. Media Service: Cloudinary for storing and serving user images.
Each subsystem interfaces through well-defined APIs or event channels.

4.2 Procedural Approach

Although largely event-driven, core business logic follows modular procedures:
• Authenticate user → initialize session → establish WebSocket.
• On message send → validate input → broadcast → store in DB.

4.2.1 Module Decomposition

• AuthModule: login(), register(), logout().
• ChatModule: sendMessage(), fetchHistory(), retryPending().
• ProfileModule: uploadImage(), updateDetails().

4.2.2 Data Decomposition

• User Data: segmented into credentials, profile metadata, status logs.
• Message Data: separated by direct messages vs. group chat (future feature).
4.3 Object-Oriented Approach
Although JavaScript is multi-paradigm, we model key entities as classes for clarity.

4.3.1 Use Case Diagrams

4.3.2 Class Diagrams

4.3.3 Sequence Diagrams

4.3.4 State chart Diagrams
4.3.5 Activity Diagrams
5. Dependency Description
Dependencies are captured in a matrix of entities versus resources:
• AuthController → EncryptionUtils, UserRepository.
• ChatService → SocketService, MessageRepository.
• Frontend Components → REST API, WebSocket endpoints.
External dependencies include Node.js libraries, third-party services (Cloudinary), and
browser features (WebSocket support).

6. Interface Description
External Interfaces
• REST API:
• POST /api/auth/login
• GET /api/messages/:userId
• WebSocket:
• Client emits send_message, server replies message_sent.
• Event user_status_change broadcasts { userId, status }.

Internal Interfaces
• Controllers call services, passing DTOs (Data Transfer Objects).
• Services interact with repositories returning Promises.
• Utility modules provide shared functions (e.g., validation, error formatting).

7. Detailed Design

Each entity’s internal logic is specified in pseudo-code or short English steps:

•AuthService.login(): hash password → compare with DB → generate JWT → return.
•ChatService.sendMessage(): validate content → emit to Socket.IO → insert into MongoDB
→ handle errors.
•ProfileController.uploadImage(): check file size/format → call Cloudinary API → update
User.profileUrl → return new URL.
User interface design
Fig 1: registration page

Fig2:login
 Fig 3:Home

Fig 4:Message media sending

 Fig 5:Profile page

Fig 6:Theme setting page