SoSa - The Beginning of The End

If you've been following my journey for SoSa (https://www.dhirubhai.net/company/sosa-community/) you'll know that i'm currently developing a social network and doing my best to document my success and failures along the way.

In itself what i'm developing from a purely functional perspective is fairly trivial, in it's simplest form:

Chat Rooms, DM's, Forums, Meetups, User Profiles, Achievements, Subscriptions and Advertising

You can find tutorials on how to make all of these on Youtube, but I am learning from past mistakes and so what i'm building has a few technical goals:

• It needs to be scale-able
• Must be able to handle thousands of concurrent users out the gate
• Both development and financially it must be sustainable
• I need a clear vision for the architecture so other people can contribute to the platform.
• I'm aiming for a Facebook level - never offline architecture, with the budget of a paper boy

Development has come along really quickly, today I've hit the first major architectural design decision that will impact how it achieves these in the future and I wanted to share my thought process, see what other developers and architects thought and see if I've missed anything.

Micro service Madness

The original version of SoSa was a monolith and it made it difficult to maintain but also typically meant if something broke - it all broke.

So this rebuild is being built as a series of distributed, interconnected micro-services with a common language.

The first Micro service I have built so far is the Chat Server and i'm at the stage where I need to build the authentication and profile service to handle platform wide authentication and user profiles.

Things like usernames, user ids, profile pictures, profile descriptions, permissions etc but this presents an interesting problem in how I deliver data to the client when you send it a piece of information. In our case a chat room message!

Scenario 1

Currently, this is close to how the current set up looks, just without the Auth / Profile server (It's being mocked at the moment)

1. Sender, sends a message to the chat server containing the message data and the room_id
2. The Chat server processes the message and contacts the Auth / Profile server to relay information about the user back to the client
3. The Chat Server emits the new message, containing the data it's retrieved.

Simple right?

Pros:

• The client only needs to be aware of the chat server
• One source of truth
• Controlled message structure
• Only one socket connection required

Cons

• Difficult to maintain, structure changes will need to be done at several layers
• Great for the first time the client has seen this sender but then it always receives the extra information, every chat message - even if it doesn't need it.
• Not only do the two servers need to understand how each other talks, the client does as well
• If either falls over, the servers need to handle this as well as the client

Scenario 2!

Scenario 2 tries to abstract the Chat and Auth server from each other, the client is aware of both, but the servers don't really need to talk.

1. Sender, sends a message to the chat server containing the message data and the room_id
2. The Chat server processes the message and then emits it to the end client
3. End client speaks to the Auth server to grab any profile information it needs.

Pros

• Client is only retrieving the information it needs
• Auth and Chat server don't need to be aware of each other
• If one falls over, only the client needs to know how to handle it (and will continue to work if the profile server is down)
• Profiles can contain more or less information without changing other servers to handle that

Cons

• Scaling between the client and end service will require much more initial outlay
• Client must maintain socket connections to both servers
• Software based fail-overs will be complex
• Servers will have duplicate code for connect / disconnect failovers

This solution is looking much better but there are some client side and failover concerns that could be deal breakers, also although software issues are pushed up the stack to the client more it provides more scope for things to go wrong.

Scenario 3

Scenario 3 tries to combine both 1 and 2 in a way that keeps the load on the client down, allows the client to use a common language across all services including for failover, is scalable and allows each service to handle it's own redundancy.

1. Sender, sends a message to the Socket / RabbitMQ server containing the message data and the room_id
2. The socket server relays it to it's destination service (chat server in this situation)
3. The Chat server processes the message and then emits it back to the socket server
4. Socket server relays it back to the client
5. The client can then use the same mechanism to get any profile data it needs.

Pros

• Only one socket connection required
• Client can speak a common language regardless of service
• Software based failover is based on service discovery and accessibility
• Servers don't need to be aware of each other but can communicate the same way the client can with each
• Horizontal scaling can happen at every layer transparently
• I can remove / add servers with different functionality for individual users easily without breaking other users experience
• Profiles can contain more or less information without changing other servers to handle that
• Client is only retrieving the information it needs

Cons

• There will be a message relaying overhead for the Socket / RabbitMQ server
• Added complexity could make some bugs more difficult to find

What do you think? Have I missed anything?