Software Architecture Case Studies

Follow a well defined architectural process—from understanding requirements to mapping components and selecting the technology stack—to deliver fast, secure, reliable, and maintainable architecture that maximizes client value.

Understand the system's requirements and goals to anchor the architectural process. Meet with the system analyst to discuss requirements like telemetry data, workflows, and user interface elements.

Understand non-functional requirements and how they shape architecture, guiding clients and analysts to formulate these requirements, including concurrent users, heavy loads, data volumes, and performance.

Map the components of the system to display its capabilities and moving parts, including functional and non-functional tasks, and use this non-technical map to understand and communicate with the client.

Decide with the development team which platforms will base the system, selecting back-end, front-end, and data-store options. Consider trade-offs, including multiple back-end or data stores in microservices, to prevent failure.

Software architecture is a living, evolving practice; stay with the team to help navigate dilemmas, debates, and changes as the architecture evolves through production.

Explore the architectural process used with clients, the system analyst, and developers to define non-functional requirements, build consensus, and design a practical architecture.

Understand the architectural process used in each case study, assess system and non-functional requirements, map components, and select technology stacks to design architecture.

We examine real world case studies from client projects, mapping architecture components, defining functional and non-functional requirements, and selecting technology stacks for each component.

Explore a case study on designing a human resources application for Daniel's paper-supply business, focusing on requirements gathering to build a system that manages salaries, vacations, and payments.

Define functional and non-functional requirements for a web-based system that handles crud on employees, salary changes, vacation days, and a file-based external payment interface.

Map the six components—employees, salary, vacation, view, data store, and logging—to fulfill requirements, share data via one store, and define interfaces with rest over http, queue, and file.

Design a custom logging service that reads logs from a queue, validates, and stores them in SQL Server using .NET Core, with a three-layer architecture and active-active redundancy.

View service handles browser requests and serves static HTML, CSS, and JavaScript, acting as a thin web app that relies on other services for data, with load balancer-based redundancy.

The employees service is a web api offering create, read, update, and delete operations for employees and their documents, with SQL Server storage for blob documents within the same transaction.

The salary service exposes add, remove, view, and approve or reject salary requests via a REST web API built on dotnet core, highlighting noun-based endpoints and load balancing for redundancy.

Manage vacation days via a traditional dotnet core web api. Employees view and reduce days; HR sets availability; uses put, get, and post endpoints with load-balanced redundancy.

Query the salary data monthly via a timer and send payments to the external system, implemented as a Dotnet core service with a three-layer architecture and an is-alive redundancy mechanism.

Choose Rabbitmq as the queue for the logging service, highlighting its general purpose broker role and ease of use over Kafka, since no data stream is involved.

Explore architecture diagrams of the dandeli air application, detailing the logic diagram of services (logging, view, employees, salary, vacation, payment interface), plus dotnet core, rabbitmq, sql server, and redundancy.

Explore how Mascot Auto adds software and hardware to standard cars to create autonomous systems and reliably receive telemetry data for display and analysis.

Explore functional and non-functional requirements for a web-based telemetry system, including schema-less seven thousand messages per second, persistent storage, dashboards, and data retention policies for operational and BI data.

Map the telemetry architecture from cars to gateway, pipeline, processor, viewer, data warehouse, BI app, and archive, detailing data flow, validation, and separate operational versus aggregated data.

Learn how the telemetry gateway receives car telemetry over TCP and quickly pushes it to the pipeline using a high-performance Node.js service on Linux with three load-balanced instances.

Discover the telemetry pipeline as a high-volume data queue, compare in-house, custom, and third-party options, and decide to use Apache Kafka for scalable, highly available streaming.

Process messages through a three-layer telemetry processor that validates and stores them in operational MongoDB and an Azure archive, using Kafka, NodeJS, and a load-balanced, redundant service.

Explore the telemetry viewer web app, built with NodeJS and React, offering live telemetry and latest errors via a three-layer API with MongoDB storage and a load balancer for redundancy.

Define a high-level BI solution by selecting the technology stack and involving a BI expert, while using the BI tool to analyze telemetry data, produce reports, and answer performance questions.

Examine architecture diagrams for a telemetry system, from data ingestion to archival and analysis. Discover the tech stack—NodeJS, Kafka, MongoDB, and Azure Storage—plus load balancing and high availability.

Introduce Grow Skull grocery collection service, where customers create online shopping lists and employees collect and deliver orders using tablets. Define the collection-side requirements and design the employee workflow.

Map the offline-capable shopping list system with the queue, list receiver, list service, tablet interface, list database, and export to the payment engine, emphasizing service autonomy and rest api messaging.

The list receiver pulls shopping lists from queue and stores them in MySQL data store, using partitioning and a Java-based console or service setup with a consumer group for redundancy.

Expose a Web API for employees to query lists by location, mark items collected or unavailable, and export payments, using Java with three-layer architecture and MySQL behind a load balancer.

Design front end to display shopping list, mark items as unavailable or collected, and send list to the payment system via a web-based React Native user interface with offline support.

The list data component functions as a queue that stores payment data for the external payment system, reusing the existing queue to implement the data queue and complete the architecture.

Explore architecture diagrams detailing four logic components—list receiver, list service, front end, and data queue—and their Java, MySQL, and React Native stack, with redundancy via consumer group and load balancing.

Explore the payroll payment processing system's fully automatic workflow, from receiving source files to validating, processing, and issuing bank instructions for payments, with no human interaction for reliability and speed.

Define functional requirements to receive, validate, and process formats. Create unified bank file and place it in a monitored folder; enforce one-minute processing, zero data loss, seven years of logs.

Map the components of a payroll system by detailing file intake, validation, and processing across folders, queues, and formatters to produce bank-ready payment files while preserving seven years of logs.

Queues pass payloads between logic units, balance load, and persist messages for durability in an asynchronous, ui-less system; compare rabbitmq and kafka, and choose rabbitmq for easy setup.

Implement a continuous file handler that monitors folders, pulls files, and enqueues them as a console or service; choose a cross-platform, high-performance dotnet core solution with strong threading.

Validate and convert files from various formats into a unified format using per-format formatters, then queue them for processing in a Dotnet core architecture.

Receive files from queue, perform calculations, and push results to next queue. It mirrors the file formatter and supports modular dotnet core architecture with a consumer group for redundancy.

Implement the file exporter to receive files from a queue, store them in the banks folder, and hand them to the bank system for payment, enabling a queue-based flow.

Define logs component using elastic stack to store, visualize, and analyze seven years of two terabytes of banking logs, shipping from dotnet core with Serilog and rabbitmq via logstash.

Analyze a queue-based architecture case study built with dotnet core, featuring a file handler, file format converter, calculation component, exporter, and logs powered by rabbitmq and elastic stack.

Explore how diverse architectures—from a payment-enabled web app with the is alive redundancy algorithm to a high-volume IoT telemetry system using Kafka—handle offline apps, queues, and robust logging.