Requirements for Chat

A chat room, or room for short, belongs to one course and holds a flat list of messages. There are two kinds of room:

• A public room is open to everyone in the course, such as a room called General.
• A private room is open only to its members, such as a room for one project team.

We call everyone who may read a room and post to it a member of the room. Every participant in the course is a member of a public room. The members of a private room are the participants who were added to it.

Functional requirements

Chat’s first release must satisfy these functional requirements:

• When an instructor creates a public room in a course, Courselore must let every participant in the course read the room and post to it.
• When an instructor creates a private room, Courselore must let the instructor choose its members from the course’s participants.
• Courselore must let an instructor add a member to a private room and remove one. When a member is removed, Courselore must stop the member from reading the room and posting to it.
• When a participant joins a course, Courselore must let the participant read every public room in the course, including the messages posted before the participant joined. When a member is added to a private room, Courselore must let the member read the messages posted before the member was added.
• When a member posts a message with text, Courselore must add the message to the room.
• When a member opens a room, Courselore must show the room’s messages, newest first, and load older messages as the member scrolls up.
• When a member has a room open and another member posts to it, Courselore must show the new message without the member reloading the page.

In the first release, only instructors create rooms. The first release also leaves out threads, likes and reactions, editing and deleting messages, attachments, mentions, notifications, and search.

Quality attributes and constraints

• Latency: When a member posts a message, Courselore must show it on the screens of the room’s other members who have the room open within one second, under normal network conditions.
• Scalability: Courselore must meet the latency target with 1,200 open clients and 2 new messages a second. That is twice the load we estimate below.
• Technical constraint: Chat must be a feature of the existing Courselore. It must use Courselore’s relational database, its REST API, and its one deployment boundary.

Load assumptions

These numbers are my assumptions, not Courselore’s real figures:

Sixty courses with 50 participants each is 3,000 people. At the busiest hour, one in five of them has Courselore open in a browser. That is 600 open clients.

The 3,000 people post 30,000 messages a day. The busiest hour has 10 percent of them: 3,000 messages in an hour of 3,600 seconds. That is about 1 message a second. We design for the busiest hour.

At about 300 bytes each, 30,000 messages take $30,000\times 300$ bytes. That is about 9 MB a day. A semester has about 100 days, so a semester of messages is about 1 GB.