architecture for the application

Question

I am implementing some kind of web application that has basic social network functionality and browser text game. I do it basically for myself only in order to learn couple of things. (like using websockets and full-stack development)

So the architecture I came up with looks like this

Generally my web pages consist of

1. static resources that I provide with the deployment unit (inside war for example)
2. external resources that I decided not store inside war (for it to have small size) like music, images, spreadsheet. I keep them on cloud storages like google drive and mega
3. static resources like game data - quest information, skill descriptions etc. that I stored in document database.

Brief description of services

• Core Application is the main endpoint where user have access and spend most of his time
• Authentication Service (I currently design this one) is just a service that supposed to provide authorization tokens (because generally I want to support authentication - it is a web site after all - from Google or Facebook etc.). It uses relational database to store user logins, roles, permissions.
• Resource Managing Service is a single entry point for all services to access the resources - basically I wanted to centralize access to all the resources
• Player Service accumulates player statistics (in relational database) and inter-player relationship (thus graph database)
• Rule Engine Service is responsible for evaluating player data against spreadsheet that contains game rules (how the player is leveling etc.).

I am planning to introduce some communication module that would allow players to chat but there is a long way to go until then.

As I have a tendency to over-engineering, I decided to ask a question: Did I over-engineer or not? Also I am not sure whether I need middleware like AMQP or JMS. I presume it is a must for such applications.

My problem is that I want to use everything for free as it does not have big scale - so I have to come up with some workarounds for storing resources and environment. I use heroku to deploy my application and so I use add-ons for it like grapheneDB or coralogix. (maybe I will switch to aws someday)

So could anybody evaluate my architecture?

Answer 1

If this technical architecture is the simplest possible solution that solves your business problem, then it's great, you didn't over-engineered it. But your description is not enough for me to understand if this is the case.

First of all, what are my personal criterias if the architecture is ok? In other words, what what characteristics my services should possess?

• First of all, it's low coupling. I don't want my whole system to crash because of one service is down.
• I want my services to be highly cohesive. If I'd need to some piece of functionality, I want to do it in a single place.
• I don't want my service to be chatty. So I want them to have a correct granularity.
• I want them to be autonomous, thus communicating primarily via events and have decentralized data.

In order to do that you need to identify your business-architecture first. In other words, you need to identify the logical parts of your system, what they comprise of an how they communicate with each other. I use the technique called Business-capability mapping. It comes down to the following:

• Identify your higher-level business-capabilities. Think of what steps your system should go through to achieve its goals.
• Delve deeper within each service.
• Alongside two previous points think of the way how your services should communicate.

What helps me is imagining how a system worked, or would work a hundred years ago. Basic logical parts stay the same, basic communication paths do either.

This is primary activity, the one you should begin with. The other things like mongo, graph databases and the like goes after.

Here is an example of an approach I outlined.

Answer 2

Did I over-engineer or not?

It depends, sort of, on what we mean by over-engineering.

You are showing 3-4 different storage technologies, SQL, Graph, MongoDB, and a Resource Manager. It is hard to know if that is or isn't overkill without getting deeper in to the other aspects of the architecture, but does beg the question.

However, there are other aspects to engineering, such as requirements gathering, use cases, non-functional specifications (e.g. performance requirements at expected load), conceptual architecture, etc..

You might consider using a methodology or design framework in engineering a solution. Something like DDD and/or other. Formal or more informal. Being more formal might also be considered over-engineering, especially in contrast with popular Agile methodologies.

You're using color to distinguish certain classes of entities and relationships, so that's a good start. You might define those colors using a legend of some sort. Also labeling arrows is generally a good thing when communicating architecture via diagrams.

You've focused mostly on technological choices for implementation, which we might consider part of logical and/or physical architecture.

There's higher level architecture that can be described, if you like, which might go to contextual or conceptual architecture.

For example, you might document your persistent data structures at a conceptual or logical level on the one hand, and on the other hand, behaviors and responsibilities of the system and its components. Various workflows through the application and components.

For example, there's not a lot of clarity on what the output of the Rules engine is, when/how it is used; it has a relationship to the Core Application but not the Player statistics, which seems possibly inconsistent with the textual description.

In summary, the multiple databases, without rationalizing architecturally justifying them might be considered over engineering (in the sense of over building). On the other hand, the amount of detail conveyed in the architecture diagram might be considered under engineering, without some additional documentation accompanying the diagram.