𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 In their book "Continuous Architecture in Practice," authors Murat Erder, Pierre Pureur, and Eoin Woods introduced the critical ideas of continuous architecture. The main topics in this architecture are: - Moving from top-down perspective design to evolving shared design  - Introducing artifacts, such as styles & patterns, principles and decisions It includes the following activities: 𝟭. 𝗣𝗿𝗼𝘃𝗶𝗱𝗶𝗻𝗴 𝗹𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 - Do more leadership and less managing, i.e., allow the team to do the architectural work 𝟮. 𝗙𝗼𝗰𝘂𝘀 𝗼𝗻 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗮𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝘀 - Don't be obsessed with features, but the right balance with scenarios 𝟯. 𝗗𝗿𝗶𝘃𝗶𝗻𝗴 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀 - Use technical leadership group to make and implement decisions and capture them in an accessible way (ADRs) 𝟱. 𝗠𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗱𝗲𝗯𝘁 - Using a unified backlog for visibility and prioritization. 𝟲. 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗶𝗻𝗴 𝗳𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗹𝗼𝗼𝗽𝘀 - Measuring quality attributes in automated and manual ways. Continuous Architecture Principles are: 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 𝟭: 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝘀. Evolve from projects to products. Architecting products is more efficient than just designing point solutions to projects and focuses the team on its customers. 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 𝟮: 𝗙𝗼𝗰𝘂𝘀 𝗼𝗻 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗮𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝘀 rather than on functional requirements. Quality attribute requirements drive the architecture. 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 𝟯: 𝗗𝗲𝗹𝗮𝘆 𝗱𝗲𝘀𝗶𝗴𝗻 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀 𝘂𝗻𝘁𝗶𝗹 𝘁𝗵𝗲𝘆 𝗮𝗿𝗲 𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝘆. Design architectures based on facts, not on guesses. There is no point in designing and implementing capabilities that may never be used—it wastes time and resources. 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 𝟰: 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁 𝗳𝗼𝗿 𝗰𝗵𝗮𝗻𝗴𝗲. Leverage the "power of small." Big, monolithic, tightly coupled components are complex to change. Instead, leverage small, loosely coupled software elements. 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 𝟱: 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁 𝗶𝘀 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗹𝗲 𝗳𝗼𝗿 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴, 𝘁𝗲𝘀𝘁𝗶𝗻𝗴, 𝗱𝗲𝗽𝗹𝗼𝘆𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗻𝗴. Most architecture methodologies focus exclusively on software building activities, but architects should also be concerned about testing, deployment, and operation to support continuous delivery. 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 𝟲: 𝗠𝗼𝗱𝗲𝗹 𝘁𝗵𝗲 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗼𝗳 𝘆𝗼𝘂𝗿 𝘁𝗲𝗮𝗺𝘀 𝗮𝗳𝘁𝗲𝗿 𝘁𝗵𝗲 𝗱𝗲𝘀𝗶𝗴𝗻 𝗼𝗳 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝘆𝗼𝘂 𝗮𝗿𝗲 𝘄𝗼𝗿𝗸𝗶𝗻𝗴 𝗼𝗻. How teams are organized drives the architecture and design of the systems they work on. #softwaredesign

𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻: 𝗛𝗼𝘄 𝘁𝗼 𝗗𝗲𝘀𝗶𝗴𝗻 𝗜𝗻𝘀𝘁𝗮𝗴𝗿𝗮𝗺 In this post, we continue with the system design series. Let's first discuss the requirements: 𝟭. 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁𝘀: Functional requirements: - Upload images from a mobile client - Users follow other users - Generate a feed of images - Scale: 10 million users / upload 2 photos per month, wherever photo have 5MB -> 100TB month -> 1.2PB per year Non-functional Requirements: Our system should be available. In the case of any web service, it’s a mandatory rule. The system should also be reliable, which means any uploaded photo by users should never be lost. 𝟮. 𝗗𝗲𝘀𝗶𝗴𝗻 𝗱𝗮𝘁𝗮 𝘀𝘁𝗼𝗿𝗮𝗴𝗲 First, we create three tables to hold users, photos, and followers: - User (name, email, location, lastLoginTime) - Photo (user_id, title, location, URL, creationDate) - UserFollow (from, to) 𝟯. 𝗗𝗲𝘀𝗶𝗴𝗻 𝘀𝘆𝘀𝘁𝗲𝗺 The next step is to design the system. The first flow is when we have uploaded the image. From the mobile device, we hit the API gateway (single entry point for all clients), which then hit Load Balancer before going to the write App server. The load balancer is here to distribute the user traffic to many servers. Here, we keep many copies of the component to remove the single point of failure in the system, making it highly available. This server writes the image metadata to the Metadata DB, while the image is written to the Azure Blob/ AWS S3 or similar service. To support millions of users, we need to partition our database to divide and store our data into different DB servers. We can use database sharding for metadata. If we partition metadata DB based on ‘UserID,’ we may keep all the user photos in the same shard. One User seems to have almost 3 TB of data. If one DB shard is 1TB, we will need three data shards for each User. Reading the images from the system is done via the App server (read), which reuses the cache (e.g., Redis), which reads metadata from the Metadata DB and returns it to the client, which then reads the image itself from the Blob/S3, or do this via CDN close to him. The third option is a feed of images the user sees in the app. Here, we can use the Feed Generation service, which reads data from the Cache or Metadata DB. Users can get the latest newsfeed from the server using two approaches: - 𝘗𝘶𝘭𝘭-𝘉𝘢𝘴𝘦𝘥 𝘈𝘱𝘱𝘳𝘰𝘢𝘤𝘩. In this approach, each User may poll the server after a regular interval to check if any friend has a new update. The server has to find all the user connections and check for each friend to create a new post. If there are new posts, the database’s query will get all the recent posts created by a user’s connections. - 𝘗𝘶𝘴𝘩-𝘉𝘢𝘴𝘦𝘥 𝘈𝘱𝘱𝘳𝘰𝘢𝘤𝘩. In this approach, servers can push new data to the users as soon as it is available. Users must maintain a long polling request with the server to receive the updates. #softwarearchitecture #systemdesign #programming

𝗧𝗵𝗲 𝗙𝗿𝘂𝗴𝗮𝗹 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁 Dr. Werner Vogels at AWS re: Invent 2023 shared his view of the frugal architect. He mentioned three pillars: 𝟭. 𝗗𝗲𝘀𝗶𝗴𝗻 🔹 𝗠𝗮𝗸𝗲 𝗖𝗼𝘀𝘁 𝗮 𝗡𝗼𝗻-𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁: To balance features, time-to-market, and efficiency, consider costs early and often when designing, building, and operating systems. 🔹 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝘁𝗵𝗮𝘁 𝗟𝗮𝘀𝘁 𝗔𝗹𝗶𝗴𝗻 𝗖𝗼𝘀𝘁 𝘁𝗼 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀: When income permits, architect systems to achieve economies of scale in line with the profit levers of the business model. Unchecked expansion depletes value in the absence of profitability. 🔹 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝗶𝗻𝗴 𝗶𝘀 𝗮 𝗦𝗲𝗿𝗶𝗲𝘀 𝗼𝗳 𝗧𝗿𝗮𝗱𝗲-𝗼𝗳𝗳𝘀: Every design decision has trade-offs. It's crucial to regularly re-evaluate technical and business trade-offs and invest in resources aligned with business needs. 𝟮. 𝗠𝗲𝗮𝘀𝘂𝗿𝗲 🔹 𝗨𝗻𝗼𝗯𝘀𝗲𝗿𝘃𝗲𝗱 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗟𝗲𝗮𝗱 𝘁𝗼 𝗨𝗻𝗸𝗻𝗼𝘄𝗻 𝗖𝗼𝘀𝘁𝘀: Despite the initial cost, monitoring systems help businesses identify inefficient procedures, expedite processes, and strategically assign resources to top priorities. 🔹 𝗖𝗼𝘀𝘁 𝗔𝘄𝗮𝗿𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 𝗖𝗼𝘀𝘁 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝘀: With robust monitoring in place, you can take action in areas where you have identified opportunities for improvement. By implementing granular controls, you can optimize for both cost and user experience. 𝟯. 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲 🔹 𝗖𝗼𝘀𝘁 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗜𝗻𝗰𝗿𝗲𝗺𝗲𝗻𝘁𝗮𝗹: Finding cost-effectiveness is a continuous process. Keep an eye on your systems to spot trends and eliminate inefficiencies. System reviews are necessary for ongoing optimization to identify potential improvements. 🔹 𝗨𝗻𝗰𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝗱 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗟𝗲𝗮𝗱𝘀 𝘁𝗼 𝗔𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻𝘀: Always ask yourself why something worked in the past. Despite prior triumphs, review techniques and resources. "We've always done it this way" is one of the most harmful expressions in English, as Grace Hopper infamously said. #technology #cloudcomputing #aws