According to Wikipedia:A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

Who is an architect?

<ul><li>Excellent communication skills; both verbal and written. You are involved in many decision making processes.</li><li>Broad and deep technical knowledge. You are an expert in a few technologies, and you have a good understanding of many other ones.</li><li>Organizational and leadership skills</li><li>System design skills</li></ul>

Software Architect skills

<ul><li>Identify business requirements and design a system around them</li><li>Choose technologies for each high-level component, and decide how components communicate with each other</li><li>Do architectural and code reviews</li><li>Write project documentation</li><li>Set up development standards</li><li>Improve architecture during the next system release, based on the system's performance in production</li></ul>

Software Architect responsibilities

Have you ever wondered what career opportunities a developer has? What directions are open, beyond what horizons to grow. And most importantly, where are developers beyond the age of 45? Is there a…

Software Architecture

What do Software Architects do?

Systems can be scaled:<ul><li>Vertically - by increasing the resources of a specific node (more CPU, memory, disk etc.). This is easier to do, but it's limited. You can only add so many CPU cores and memory.</li><li>Horizontally - by adding more nodes of the same kind. This usually requires adding a load balancer in front of your nodes to distribute the load evenly.</li></ul>

Scaling

Joins in relational databases get very slow as the system grows bigger. You should denormalize your data to avoid joins and speed up your queries.Normalized databases are designed to minimize redundancy, while denormalized databases are designed to optimize read time.

Database denormalization

Sharding means splitting your data across multiple nodes. This can be done in different ways:1. Vertical sharding<ul><li>Store tables on different nodes.</li><li>Drawback: If one of these tables gets very large, then you need to re-shard that database.</li></ul>2. Key-based sharding<ul><li>Use part of your data (usually the row ID) to shard it.</li><li>Drawback: The number of nodes is fixed. If you want to add more nodes, then you have to reallocate the data.</li></ul>3. Directory-based sharding<ul><li>Maintain a lookup table for where each data is found.</li><li>Drawback: The lookup table is a single point of failure, that's constantly under load.</li></ul>

Database sharding

Caching systems are usually in-memory key-value databases that provide very fast access to data. They sit between your application and the database.Depending on your use case, you can either cache only the results of the database queries, or cache the entire response objects (such as fully rendered web pages).

Caching

Slow operations should be done asynchronously to avoid making users wait for long periods of time until their requests are processed.Sometimes this can be done in advance, by pre-processing data that you know users will need. For example, a forum might periodically re-render its page of most popular posts and the number of comments.Asynchronous processing usually requires 2 components:<ol><li>A queue that stores tasks, ordered by time and priority</li><li>A&nbsp;system that processes tasks</li></ol>

Asynchronous processing

<ul><li>Bandwidth - Maximum amount of data that can be transferred in a unit of time. Usually expressed in bits per second.</li><li>Throughput - Amount of data that is actually transferred in a unit of time.</li><li>Latency - How long it takes data to go from one end to the other.</li></ul>

Networking metrics

Key Concepts for System Design

There is no single design for any system that works perfectly. There are always trade-offs. Two different people can come up with different designs, with both being excellent given different assumptions.Your goal is to:<ol><li>Understand the use case</li><li>Scope the problem you are solving</li><li>Make reasonable assumptions</li><li>Create a solid design based on those assumptions</li><li>Be open about the trade-offs you made and the weaknesses of your design</li></ol>

There is no "perfect" system

You can't design a system if you don't know what you're designing.First, ask questions to clarify what you need to implement. Then make a list of all major features and use cases that your design must cover.For example, if you're designing TinyURL, that list might be:<ul><li>Shortening a URL to a TinyURL</li><li>Analytics for a URL</li><li>Retrieving original URL from a TinyURL</li></ul>

Step 1: Scope the problem

Depending on the type of system you are designing, you need to estimate its scale: how many users will access it every day, how much data you will store and process, etc.You should be careful when making assumptions. Incorrect assumptions can dramatically change the design. You should rely on your product sense as well to make reasonable assumptions.In the TinyURL example:<ul><li>It matters whether newly generated URLs must be accessible immediately</li><li>It matters whether URL analytics must be updated in real-time</li></ul>

Step 2: Make reasonable assumptions

Draw a high-level diagram of what your system looks like:<ul><li>Include major components such as servers, databases and important processes</li><li>Describe the flow of your system from end-to-end</li></ul>

Step 3: Draw the major components

Once you have a basic design in mind, focus on the key issues. Identify the bottlenecks and major challenges of the system, and then adjust your design to handle them.In the TinyURL example, a challenge you might consider is that some URLs are frequently accessed, while others suddenly peak when they go viral on social media. You don't want to hit the database for every request, so you could add a cache layer.

systemdesign

Who is an architect?

What do Software Architects do?

Scaling

Key Concepts for System Design