Some Notes I Took on Software Architecture

#microservices #architecture

I watched a few videos, read some stuff online about Software Architecture, and took some notes in the process.

I hope these make sense.

First of all, you want to analyze:

the functional requirements
the non-functional requirements

Functional requirements are the “what”, often captured in use cases, user stories, or a detailed list of features.

Non-functional requirements are the “how”. Like performance, reliability, security, maintainability, etc. You can look into ISO/IEC 25010 as a reference.

When planning a software architecture, you want to put structure over implementation. You need to take into consideration the budget, along with any restrictions you may have, like regulatory constraints (like HIPAA), industry standards, talent pool (the team you have), etc.

Try to spot any conflicting requirements that could be problematic along the way. Catching these earlier will save you tons of time and overhead. If something needs to be rethought, this is the time.

Prioritize the NFRs so you have a better understanding of the core business, what drives the solution, and the necessity behind it. This will make it clearer where you should focus and put more effort into, and what improvements could be added in later stages.

With all this in mind, try to imagine how this system could grow and evolve in time.

Next, you have to choose one.

And remember:

Do not forget about these three core concepts:

You should always keep these in mind.

It has to work, so it needs to be performant.

It has to be scalable , because you never know how big you can get.

Focusing on maintainability is also crucial. Maintainable systems are easier to understand, modify, and fix, benefiting both the dev experience and the client. Instead of creating something that only a few people can handle, you will build a system that is a joy to work with and a gift to those who use it.

When you have a shared state between servers (which happens with a microservices architecture, or any other type of distributed system), the CAP theorem applies.

CAP stands for Consistency, Availability, and Partition Tolerance. The CAP theorem states that Partition Tolerance is required for distributed systems, so you can only choose one of the other two.

The trade-offs usually are:

Consistency > Availability

Often used for banking or in relational databases, when you block new writes to the DB, causing the system to go temporarily unavailable.

Availability > Consistency

When writes happen at the same time, consistency may be lost. You need to implement a sorting or prioritization engine. This is often picked for social media or e-commerce apps.

I believe the most used one is A+P (Availability + Partition tolerance).

You need to manage these trade-offs gracefully, with some strategy to resolve inconsistencies quickly.

With scaling comes latency and slower response times; that’s where cache comes into play.

A cache is a component that stores data so that requests that need the same data will be served faster.

Some examples are in-memory cache, CDNs, Redis, memcached, etc.

Every layer/component of an architecture can, and should, have a cache. But you can add this in later stages, as an optimization.

And finally: