Software architecture
Fundamental decisions about a software system’s structure, interactions and quality goals.
Structure with a purpose
Software architecture describes fundamental decisions about a system’s elements, their relationships and interactions. This includes boundaries, interfaces and responsibilities. These decisions should support requirements such as modifiability, availability and access protection.
In a fictional example, a customer portal should still display jobs when report generation fails. Its architecture must clarify dependencies and failure handling. A drawing of boxes or a list of products is insufficient. Record the reasoning, important assumptions and consequences. Whether the chosen structure meets its goals needs appropriate evaluation; an architecture diagram is not evidence that the system works.
Sources
Related terms
- MonolithAn application whose core is deployed as one unit; clear internal modules are still possible.
- MicroservicesAn architecture of bounded services intended to evolve, operate and deploy as independently as practical.
- Modular monolithAn application deployed together with explicitly bounded internal modules and interfaces.
- Cache stampedeA cache stampede occurs when concurrent cache misses trigger the same expensive calculation or data query repeatedly.
- BackpressureBackpressure adjusts incoming data to the receiver’s processing capacity through signals to slow down or pause.
- Race conditionA result depends on the timing of overlapping accesses and can therefore be wrong.
Articles on this topic
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.