Architectural Design

Web Browser Architecture


This case study focuses on the tradeoffs of choosing different architectural styles (patterns) for design and development of a complex software system, such as a modern web browser, e.g. Safari, Chrome, or Firefox. Based on their current knowledge of software architecture and design, students will attempt to reverse-engineer a modern web browser and identify its primary architectural components. Based on their findings, student teams will select one architectural design pattern (e.g., layered, repository, client/server, or pipes and filters – Sommerville, Software Engineering) that offering the best fit for the architecture of the web browser. Ultimately, as a result of a discussion, students will see that, complex systems such as a web browser do not fit any of these architectures perfectly, but instead, include elements of several architectural patterns.

Learning outcomes

Upon a successful completion of this project the students will be able to:

  • Identify architectural components of a complex software system;
  • Choose a software architectural pattern fitting system requirements;
  • Produce an architectural design of a software system.


Timing considerations

Up to 60 minutes.

Number of participants

This activity works well for teams of 15-20 participants, or more. For smaller teams, it may be necessary to do more iterations to identify enough architectural components.


Each team needs a separate building space (a large table), with or without chairs. All discussions occur within a single team. Each team builds their own set of architectural components. Each team uses its own baseplates to build a model representing the system architecture.

Materials and supplies

  • LEGO sets for each team:
    • A set with a diverse combination of bricks. Suitable sets include LEGO Classic boxes, such as LEGO Classic Large Creative Brick Box 10698.
      Note: remove any minifigures from the LEGO set used for this activity. Minifigures may add unnecessary confusion by tempting students to include users/actors into architectural models.
    • Optional: One or two large baseplates per team. Suitable items include 32x32 baseplates such as 10714 or 10700.
  • Sticky notes and pens.
  • Handouts: refresher on architectural patterns (see below).
  • A whiteboard with marker(s).


Scenario of the activity

  1. Introduction: 5 minutes
    1. Distribute the handout with the refresher describing several well-known architectural patterns.
    2. Explain the nature of the problem at hand: reverse engineer a complex software system, such as a modern web browser (e.g. Safari, Chrome, Firefox, etc) and identify the most suitable architectural pattern for building it.
  2. Identify architectural components: 10 minutes per iteration
    1. Each student identifies and builds a model representing an architectural component, process, or a logical element that serves as a part of the web browser. Everyone builds individually (one student = one component = one model), in silence, with no discussions. Time: 2 minutes.
    2. Once the models are built, each student within the team very briefly (no more than 20 seconds per person) explains their choice of components. Each student writes a succinct description (1-3 words) for each model on a sticky note and places it next to the model.
      Items typically suggested by students include realistic architectural components (e.g. cache, JavaScript engine, HTML renderer, user interface, various parsers), specific parts of the user interface (e.g. address bar, reload/back/forward buttons, page tabs), and other items that may or may not be a part of the browser (e.g. antivirus and malware protection, proxies, DNS requests, user accounts, and many others). It is important not to correct anyone at this stage, even if the proposed item is clearly irrelevant.
    3. Ask students whether the current set of components is reasonably complete to represent the architecture of the browser.
      Key question to ponder: are we missing anything important? Instead of soliciting student responses, repeat this step one more time and go through another iteration of building models.
  3. Simplify the model: 10 minutes
    1. Ask students which architectural view we are building: logical, development, process, or physical? Refocus on the logical view, which includes key abstractions corresponding to system requirements.
    2. Ask if some of the components are too similar or closely related to each other. They should be merged together.
      At this point, it is important to exercise a good judgement and, if necessary, give students some hints.
    3. Ask if all components truly belong to the system. Some of them may actually belong to other systems, applications, or the operating system. Such components should be removed.
      As above, it may be a good idea to nudge students gently in the right direction, if necessary, and help them remove any clearly irrelevant components.
    4. Once the collection of components has been simplified, place the sticky notes corresponding to the remaining architectural components on the whiteboard.
  4. Architectural design and debrief: 15 minutes
    1. Divide students into several teams. Each team is assigned one of the architectural pattern listed in the handout.
    2. Each team needs to use the architectural components remaining on the whiteboard to design a web browser architecture utilizing the architectural pattern assigned to them. Point out to students that some teams may not be able to fit all remaining components with the given architectural pattern, but they must make the best effort. Time: 5 minutes.
      Important: it is usually fairly easy to fit some aspects of the web browser architecture into any pattern listed in the handout, with the exception of client/server. Client/server architecture represents the interaction between a web browser and a web server, but it is a poor choice to build the web browser itself because it is unlikely to incorporate any server features.
      Note: no LEGO needs to be involved at this time because each team will be using the same components at the same time. Each team works independently.
    3. Each team takes turns to draw their architectural diagram on the board to make the case why their architectural pattern is the best choice to build a web browser. Time: 2 minutes.
    4. Once all teams have made their case, ask all students to comment: Which pattern is the overall best fit for designing a web browser architecture? What are the advantages and disadvantages of each pattern in this case?
    5. Point out that, as with many complex software systems, the overall architecture of the web browser is likely to include elements of more than one architectural pattern (with the likely exception of client/server).

Practical observations

  • When suggesting architectural components in step 2, ask students not to criticize each other’s ideas. Everyone will have a chance to do so at a later point, at step 3. This will help centralize all feedback into a more central point in the timeline of this activity. This will also help focus any possible criticism on the model/component and detach it from the specific person who suggested it.
  • As with many other activities, its learning outcomes are fully achieved through a successful debrief. The debrief in this activity is concentrated at its very end. Do not skip it. Ensure that there is ample time for each team to discuss and present their architectural designs, to discuss the merits of each architectural pattern in this context, and to draw the conclusion about combining the elements of many architectural patterns in a complex software system.


A review of several common architectural patterns

Notes on scaling up/down

This activity has been run successfully with various number of students ranging from five to over twenty-five. With a smaller number of students, it may be necessary to run more than two iterations of Step 2 (Identify architectural components).