Module 2 - Service Design - BD Unit 7 Sprint 27

Module Overview

Explore service design principles and best practices for building scalable applications.

Learning Objectives

Identify whether AWS Lambda should not be used as the architecture for a set of business requirements
Identify trade-offs of using each of a set of alternative technologies in a provided design document to solve a specified business problem
Make a service design recommendation based on a trade-off analysis
Compare Lambda against other AWS Compute options
Outline the use case for the adapter, facade, proxy, notifier, and aggregator service design patterns

Introduction to Service Design

Service design is the process of applying your technical knowledge to build services that solve business problems. It involves selecting the right technologies, balancing requirements, and researching potential solutions.

The Service Design Process

Gather Requirements: Collect the functional and non-functional requirements for the problem you aim to solve.
Break Down Components: Divide the system into smaller, manageable subsystems and services.
Compare Alternatives: Evaluate multiple potential solutions by weighing their pros and cons.
Document and Review: Create a design document and get feedback through design reviews.

Practical Service Design Principles

Don't Reinvent the Wheel: Reuse existing components rather than building from scratch when possible.
Simplicity Over Complexity: Follow standard patterns rather than creating overly complex solutions upfront.
Limit Access to Data Stores: Create "gatekeeper" components that control access to data stores to prevent conflicts.
Build in Layers: Design components to add complexity in layers, keeping each component simpler and more modular.

When comparing technologies like AWS Lambda vs. other AWS Compute options (ECS, EC2), consider factors such as operational maintenance, flexibility, and specific requirements like statelessness, execution time limits, and memory constraints.

Introduction

You've learned a lot about programming. You've learned a lot about AWS technologies and general development practices. Service design takes that knowledge and applies it to building services that solve business problems. In this reading we'll go over service design principles and patterns. We'll also show you how to compare different potential solutions, and how to document your design.

Service design process

Solving business problems often requires us to put together different technologies, services, and other components into a cohesive design. We need to apply our knowledge of different tools and technologies to solve the problem. We must also balance different functional and non-functional requirements. As our industry is constantly evolving, solving problems also requires us to research new tools as potential solutions.

Gather requirements

Before we can start on our design, we must collect the requirements for the problem we intend to solve. For smaller technical projects, we may be responsible for gathering these ourselves. When the project is large and/or customer facing, requirements will often be provided by a Product Manager or Technical Project Manager who has spent time reviewing our customers' needs. Once we have our requirements, we can begin.

Break down components

Once we have our requirements, the first step in designing our service is to break the problem down into component pieces. If we are designing a large system (for example, the video ingestion process for Prime Video), this could mean defining smaller subsystems/services that will make up the whole (such as video upload and storage, media rental/purchase licensing, and detail page creation), each of which will be fleshed out in its own design document. In the design documents for these smaller services, the components might be the general structure of our code, the main classes we expect to build and how they interconnect. We also consider whether and how we might reuse existing services to avoid duplicating effort. Many problems will have multiple potential solutions. Before we continue, we do our best to capture all reasonable design options.

Compare alternatives

Once we have a set of potential solutions, we weigh the pros and cons of each to decide on the best approach. In our designs, we often have to strike a balance between competing goals. Maintainability, scalability, and usability are important goals. Security, simplicity, and extensibility are also essential. Depending on the specific case, any of these properties could be in direct opposition to another. Time, people, and cost are three other limiting factors in any project. The best solution may not be possible while managing these limiting factors. In fact, no solution will ever be perfect. The best solutions are those that meet the business needs while finding a balance between our various competing goals and limitations. A successful solution should leave all stakeholders happy with what was built (even if they would still like more).

As we weigh our options and come to a decision about our design, we need to document our recommendation. We communicate the details of the business problem and our proposed implementation in the design document. The design document captures the details of our solution, our reasoning for choosing that solution, and brief descriptions of alternatives considered and why they weren't chosen. This culminates in a design review. Just like a code review, a design review provides feedback and approval from the team and senior engineers. Once approved, implementation can begin!

Example: Service design

Before going into the details of service design, let's set up an example to step through the design process. Picture a new movie service where users can search for movies to stream, rent digital versions or order a physical copy. Our service ties together a few different existing services. It needs to talk to the User Account service, Payment service, and Movie Inventory service. It also needs to interface with an external Movie Info service. We'll also have external clients for searching, renting, and ordering movies. Internally, we'll have clients to manage the movies and movie data in a data source specific to this service. With this example in mind, let's review some practical service design principles.

Practical service design principles

In many professions, there are principles you learn as you gain experience. Software development is no exception. What follows are some basic principles to keep in mind when thinking about service design.

Don't reinvent the wheel

If we have an existing component, reuse it rather than building from scratch. We save development time and lower maintenance cost through reuse.

Sometimes, we have a component that is close to what we need, but would require some modification. In this case, rely on developers on your team with more experience for guidance. If the responsibilities of that service are consistent with what we need, but it is lacking certain features, it may be appropriate to add functionality to that service to fit our needs. However, just because an existing service is close to what we need doesn't mean we should bolt on more functionality, particularly if that new functionality is not related to the purpose that service fulfills.

Simplicity over complexity

It can feel impressive to design a solution with many complex pieces. However, complex designs are often hard to maintain and update. In most cases, it's better to follow standard patterns and interactions rather than specialize everything up front, even if that might mean less performant code. We can identify areas that need complex or specialized solutions by testing performance and stability once we have the basic structure in place. It's better to add complexity only where we need it, not have it baked into the whole system from the start.

Limit access to data stores

Allowing multiple components to make updates to the data store is a common mistake in service design. If multiple components have write access to the same data store, they may conflict with each other and cause errors. Instead, we can make a component act as the gatekeeper for the data store (like the DAOs you see in your projects and classwork). Because the gatekeeper is an avoidable component, this may seem like adding complexity. In fact, by managing all access in one component, we prevent contention and inconsistency. We also abstract away the details of the data store, so any changes affect only the gatekeeper instead of all the components that access the data. Limiting data store access to a single component actually simplifies the overall service.

Build in layers

When we add a gatekeeper in front of a data store, it follows another common design principle. Design components to add complexity in layers. That way, we can keep each component simple and modular. Monolithic design, where components handle multiple functions (like retrieving data from a data store as well as performing some business logic), requires custom components for each business problem. By breaking the components up into layers with less specialized concerns (in this example, one to retrieve data, one to perform the business logic), we create components with more potential for reuse.

Example: A Movie Service design

By taking practical service design principles and applying them to the Movie Service example, we can come up with a design that meets the requirements. You can see our initial design in Figure 1. While the diagram includes technologies used for each component, we will cover how to choose technologies for components later in this reading.

Figure 1: The Movie Service component diagram. External and internal webclients access the Movie Service (Lambda), which manages a Movie DB (DynamoDB). The MovieService also accesses User Account Service (Internal Application), Movie Inventory Service (Internal Application), Payment Service (Internal Application), and Movie Info Service (3rd Party Application).

In this design, we are managing the Movie DB with a single component, the Movie Service. We'll start the design simple by allowing the Movie Service to connect to all the other backend and third party components. External and internal clients can access the service through the same Movie Service interface. This design is fairly straightforward, but it may require a lot of logic in the Movie Service. Let's see if there are other service design principles we can apply to come up with an alternative.

Service patterns

Throughout the history of software development, many design patterns have been developed to solve common problems. Many of these patterns apply to service design. Think of design patterns as building blocks for your designs. Something these patterns have in common is that they implement a small piece of logic. While these patterns are useful tools to use in designing your solutions, don't blindly use them just because you can. You should understand why you are choosing to use a given pattern and what benefits it brings. Otherwise, you run the risk of overengineering your solution and adding complexity where it is not needed.

Adapter, facade, and proxy patterns

These three design patterns are similar, as each adds a separate interface over an existing service. The intent with each of these patterns is to allow clients to connect to a service or interface while providing some additional value. Depending on the pattern, we can improve compatibility, provide simplification, or extend functionality.

The adapter pattern

Our first pattern, the adapter, improves compatibility. It bridges incompatible interfaces and allows them to work together. For example, let's say we were pulling movie information from a Movie Inventory Service that identified movies using a SKU (stock keeping unit). If our service used a generated UUID to identify a movie, we would need to translate from SKU to UUID every time we pulled information from the Movie Inventory Service. For a problem such as this, we would create an adapter to handle the translation. That way, the rest of our Movie Service code wouldn't need to be aware of SKUs, only the adapter for the Movie Inventory Service.

The facade pattern

If we want a simplified version of an existing interface, we can turn to our second pattern, the facade. For example, let's say our Movie Service supports the standard create, read, update, and delete operations, but we want external clients to only be able to read data. To accomplish this, we can create a client that only exposes read functionality, i.e. a read-only version. This read-only client becomes a facade, or the "face" of our service.

Note: there are alternatives to this pattern, such as controlling user's access within our Movie Service. It's important to consider multiple solutions when designing your service.

The proxy pattern

We use the proxy pattern to provide additional functionality to an interface without touching the original. Proxies are commonly used to protect an application from changes outside of our control. A proxy in front of external or vendor supplied services can isolate a change in one component instead of allowing the change to spread throughout other components in our application. Since the Movie Info Service is a 3rd party application, we can use a proxy service that our Movie Service calls instead.

The notifier pattern

We use the notifier pattern when we need a flexible way to listen for events and be notified when they occur. Typically, this is handled by a service for registering interested parties, a listener for events, and logic that sends updates to the interested parties when events occur. The notifier pattern allows multiple parties to register for notifications, and decouples event occurrence from the sending of notifications. Amazon CloudWatch is like a giant notifier service. It can collect data when events occur anywhere in your AWS account, and it can be configured to trigger other actions when certain events are logged.

The aggregator pattern

The aggregator pattern gathers data from different sources and builds a combined response from the resulting calls. This simplifies client logic by keeping all the retrieval and aggregation code separate. Instead of making multiple calls to various data sources, the client makes one request and receives all the data it needs. Aggregators are common in situations where we have multiple places in our code that need a set of data that comes from many sources, or where the retrieval of that data requires complex logic.

Example: Service design with patterns

Figure 2: Version 2 of the Movie Service component diagram. External web clients access the Movie Service (Lambda) through a Movie Service Client Facade, while internal web clients access Movie Service directly. Movie Service manages a Movie DB (DynamoDB) and accesses a Movie Service Aggregator (Lambda). The Movie Service Aggregator accesses User Account Service (Internal Application), Movie Inventory Service (Internal Application), Payment Service (Internal Application). It also accesses Movie Info Service (3rd Party Application) through Movie Info Proxy Service (Lambda).

In this design, we've added more layers to our service design. There's still a central Movie Service with a Movie database. However, we added a facade (Movie Service Client Facade) to expose only the operations needed to external clients. We also added a proxy in front of the third party Movie Info service. A new aggregator component (Movie Service Aggregator) gathers data from the three internal and one external source. Now the Movie Service only needs to manage the Movie database and access the aggregator service.

We've shown examples of using the patterns, but this is for a hypothetical service with its own set of requirements. When designing, it's important to only apply these patterns when a problem comes up that blocks the key attributes of a service like maintenance, scalability, etc. Keep in mind the original problem you set out to solve, and incrementally use these patterns as your service grows. Overengineering is a very real and easy anti-pattern to fall into.

Trade-offs

Once we have some ideas for potential solutions, we evaluate those solutions to compare their pros and cons. By putting together lists of the strengths and weaknesses of each solution, we can better compare alternatives to each other. This more detailed analysis could reveal that an idea we favored has a flaw that makes it a bad fit, or that an out-there solution we thought probably wouldn't be best actually provides unexpected benefits. Options with weaknesses where it comes to long-term maintenance, extensibility, and costs accrue technical debt. Think of technical debt as the penalty incurred for choosing the quick and easy option now instead of a more involved option with a better long-term outlook. However, the opposite can happen as well -- overengineering a solution that splits the components into too many or too complex pieces can make it difficult to understand and maintain the service.

Next, we compare our options and choose one to recommend. By providing the alternatives we considered and the reasons we prefer our recommendation, we invite other developers to provide insight while simultaneously avoiding questions about trade-offs we've already considered. We compile all the options, considerations, and our final recommendation into a design document.

Example: Trade-off analysis

Since we have two design alternatives for our Movie Service, let's compare the trade-offs of the first Simple Design vs the second Patterned Design.

Design Comparison

Simple Design

Fewer components to maintain
Cheaper to build
Fewer interfaces to design
Less data moving among components

Patterned Design

More opportunities to reuse pieces
More components to use in performance tuning
More resistant to changes in source systems (with aggregator and proxy)
More secure with facade
Easier to break up work among a team
Components individually have simpler logic requirements

Based on what we know of our Movie Service, the patterned design seems preferable. However, a design with more pros doesn't necessarily mean it will be the best recommendation. For example, it might make sense to incrementally evolve the simple design into something that looks more like the patterned design as your service grows. There's no one-size-fits-all or "best" solution, these patterns are more tools for you to use to solve problems throughout your software development career.

Design review

To communicate our recommendation and get feedback from our team and other stakeholders, we create a service design document that describes the design and discusses its strengths and weaknesses. We also discuss potential alternatives, especially why we prefer our recommendation. Our goal is to answer any questions our teammates may have about the design, from alternative options they might recommend to how we plan to address or mitigate the weaknesses our recommended solution has. The completed document will then be used to perform a design review with senior engineers. As with a code review, they may provide feedback that we need to address. Once a satisfactory design is created, documented, and approved, development on our service can begin.

Design document contents

We always begin a design document by describing the problem being solved. It should not be a regurgitation of the requirements, but we do want to provide a summary of the project and some of the major requirements.

After the problem description, we want to outline the proposed solution. Our solution section should include a diagram of the components with lines and labels showing how the components interact. Use the rest of this section to describe what each component does. It's a good idea to include a subsection outlining the pros and cons of the design. We also want to include reasoning for choosing this design over other alternatives.

In the last section of the design document, we provide design alternatives. These may be completely different from the recommended design or provide different options for just parts of the recommended design. Each of these alternatives should include at least a short description, and maybe a component diagram. Be sure to highlight the differences from the recommended design. You should summarize the pros and cons for each alternative, and explain your reasoning for not choosing this alternative over your recommendation. Our purpose in this section is to communicate viable alternatives and why we prefer the recommended design.

Design diagrams

Figure 3: Example of a component diagram for an Account service which connects to a data store and two vendor applications.

Component diagrams are an important way to visually communicate each prospective design. Let's look at what they should include. Consider our example in Figure 3. First, the diagram should include a box for each service component. Each component should be named and include the relevant technology (e.g. Lambda, DynamoDB). We connect the components using directed lines indicating which services call which. For example, if a component calls multiple services behind the scenes, the diagram should show multiple lines with arrows pointing from that component to those services. The same is true for components accessing a data store.

For the alternative designs, we only need a simplified diagram showing the changed components in the layout. If a full diagram is shown, be sure to visually indicate which components are different with more than just text changes, like different colored boxes, or an outlined section. When we have clear diagrams, it's easier for reviewers to see differences between the alternative and the original.

In our two Movie Service examples, each has a component diagram showing what the components are, what technologies are needed, and where other components connect. Without the diagram, we'd have much more work trying to communicate the same information with just words. Think of the component diagram as the map with the description serving as the directions.

AWS technology comparisons

AWS offers many technology choices that we can use in our solutions. Many service design choices come down to deciding which technology to use when implementing a component. When comparing technologies, it's good to know where different options are better or worse for various roles in the architecture. For example, should we use AWS Lambda for running code in a service? Perhaps using Elastic Container Service (ECS) would be a better choice. Without thoroughly comparing the options, we could create fundamental weaknesses in our service that wouldn't show up until later in implementation or even after we've launched our service.

Lambda vs other AWS Compute options

When it comes to running code in the cloud, AWS has three major options. Our first option is Lambda, a serverless compute service. Lambda compute services require very little operational maintenance.

However, it also offers less flexibility compared to our other two options.

The second choice is ECS, a serverless container solution, like the docker containers we use for most ATA projects. ECS sits in the middle of the road when it comes to operational resources required and flexibility. Our third option is Elastic Cloud Compute (EC2). EC2 is a cloud-based virtual machine hosting service. EC2 offers the most flexibility, at the cost of requiring more resources devoted to running the operational aspects of the service. Most often at Amazon, teams will choose between Lambda or ECS.

Lambda services are the most common technology on AWS, so let's look more closely at how they function. Lambdas are serverless compute containers. We call them serverless because all the management of setting up and configuring a server is handled for us by AWS. All we need to do is write the code and deploy it. Lambda automatically spins up instances when requests come in to run the code. It creates more instances as needed to handle incoming requests. It's important to note that the operations written using Lambdas must be stateless, since they shut down between requests, so no state is shared between instances. This means each request is handled independently. Nothing is kept in memory between calls. If state must be kept, you would need to save it in a data store where all Lambda instances could access it. Lambda services have many benefits. They have low operational management requirements after deployment. They also have automatic scaling of services, and simplicity of creating services.

For small services and components, Lambda is the way to go. As long as you're using a language supported by the service (which include Java, Python, and Node.js, to name a few) and do not have special operational needs, then Lambda should be your choice. It's scalable and easy to develop for, plus the costs scale based on usage. That said, there are several areas where Lambda is not well suited:

Components that cannot handle occasional warm-up times after a period of inactivity. As part of the automatic scaling, Lambda services may sometimes wind down all instances when no requests are coming in. When this happens, a new request will need to wait for a new instance to start up before being handled.
Large, complex codebases or interactions that exceed the platform's limits. Some of the current limits include 3,008 MB maximum runtime memory, 15-minute operation timeout, 50 MB maximum zipped deployment package (250 MB unzipped), and 6 MB maximum request/response size (256 KB for asynchronous requests).
Situations requiring more flexible operational configuration such as complex networking requirements or host configuration.
Stateful services (though these components should be implemented using data stores). Recall that stateless services keep nothing in memory from one request to another. Stateful services are services that keep information in memory between calls.
Operations that need to run for a long time. This is related to the platform limits, but it can be an issue if many other services are called behind the scenes while waiting to respond.
Any services that need a long-running thread. When a Lambda instance finishes its execution, any background threads will also stop executing!

When creating a service design, we consider these factors when deciding whether to deploy our service on Lambda. As long as the service doesn't have any of the above requirements, Lambda is a good choice. Otherwise, we must choose ECS to fulfill our requirements.

DynamoDB vs RDS

Data stores are another major component in service design. AWS has many types of data stores. Two major options are DynamoDB and Amazon Relational Database Service (RDS). Choosing the right one for a service component impacts performance and cost. It also affects routine maintenance and future extensibility. In most cases, DynamoDB will be the best choice, but even it has its weaknesses.

If you need to pull data using a great deal of complex sets of fields combined from multiple tables.
If records will exceed DynamoDB's record size limit (400 KB).
If the application absolutely requires a relational database (code framework or vendor software).

These are high-level overviews, more in-depth information can be found in the AWS documentation for all the services we talked about that can help you decide what technology to use.

Conclusion

Your service design skills will grow with time and experience. This reading provided some principles and patterns to assist you in designing services. Try to recognize these patterns as you work on existing services. Seeing them in action should help you understand when to apply them when designing new ones. In addition to this starter toolset, lean on the experience of others by running ideas by other engineers or subject matter experts. Keep in mind that designing a service is almost always a collaborative process. To that end, we also explained how to prepare for a design review by comparing various options and documenting your recommendations. Over time, your service design toolset will grow, especially as you learn new patterns, research new technologies, and work with other engineers.

Service Design Patterns

Throughout software development history, design patterns have evolved to solve common problems. These patterns implement specific pieces of logic and serve as building blocks for your designs.

Adapter Pattern

The adapter pattern improves compatibility by bridging incompatible interfaces to work together. It translates between different interfaces or data formats.

Example: Translating between different ID formats (e.g., converting SKUs to UUIDs) when integrating with other services.

public class InventoryServiceAdapter {
    private InventoryService inventoryService;

    public InventoryServiceAdapter(InventoryService inventoryService) {
        this.inventoryService = inventoryService;
    }

    public MovieInfo getMovieInfo(UUID movieId) {
        // Convert UUID to SKU format expected by inventory service
        String skuId = convertToSku(movieId);
        
        // Call the inventory service with the converted ID
        InventoryItem item = inventoryService.getItem(skuId);
        
        // Convert the result back to our domain model
        return convertToMovieInfo(item);
    }
    
    private String convertToSku(UUID movieId) {
        // Implementation details...
    }
    
    private MovieInfo convertToMovieInfo(InventoryItem item) {
        // Implementation details...
    }
}

Facade Pattern

The facade pattern provides a simplified interface to a complex subsystem. It hides the complexity by providing a single entry point that forwards requests to the appropriate components.

Example: Creating a simplified API that coordinates interactions with multiple microservices.

public class MovieRecommendationFacade {
    private UserService userService;
    private MovieCatalogService catalogService;
    private RatingService ratingService;
    
    // Constructor with dependencies injected
    public MovieRecommendationFacade(UserService userService, 
                                     MovieCatalogService catalogService,
                                     RatingService ratingService) {
        this.userService = userService;
        this.catalogService = catalogService;
        this.ratingService = ratingService;
    }
    
    // Simplified API that coordinates multiple service calls
    public List getRecommendationsForUser(String userId) {
        User user = userService.getUser(userId);
        List genres = user.getPreferredGenres();
        
        // Get top-rated movies in user's preferred genres
        List candidates = catalogService.getMoviesByGenres(genres);
        
        // Filter and sort based on ratings
        List ratings = ratingService.getRatingsForMovies(
            candidates.stream().map(Movie::getId).collect(Collectors.toList()));
        
        // Process and return final recommendations
        return processRecommendations(candidates, ratings, user);
    }
    
    private List processRecommendations(
            List movies, List ratings, User user) {
        // Implementation details...
    }
}

Proxy Pattern

The proxy pattern provides a surrogate or placeholder for another object to control access to it. It can add additional functionality like caching, access control, or logging.

Example: Implementing a caching layer in front of an expensive data retrieval service.

public class CachingMovieCatalogProxy implements MovieCatalogService {
    private MovieCatalogService realCatalogService;
    private Map> genreCache = new HashMap<>();
    
    public CachingMovieCatalogProxy(MovieCatalogService realCatalogService) {
        this.realCatalogService = realCatalogService;
    }
    
    @Override
    public List getMoviesByGenres(List genres) {
        // Create cache key (e.g., genres sorted and joined)
        String cacheKey = genres.stream().sorted().collect(Collectors.joining(","));
        
        // Check cache first
        if (genreCache.containsKey(cacheKey)) {
            return genreCache.get(cacheKey);
        }
        
        // Cache miss: get from real service and update cache
        List movies = realCatalogService.getMoviesByGenres(genres);
        genreCache.put(cacheKey, movies);
        return movies;
    }
    
    // Implement other methods from MovieCatalogService interface...
}

Aggregator Pattern

The aggregator pattern collects related data from multiple services and combines them to provide a single, unified response to clients.

Example: Creating a composite view of product details from inventory, pricing, and review services.

public class ProductDetailsAggregator {
    private InventoryService inventoryService;
    private PricingService pricingService;
    private ReviewService reviewService;
    
    // Constructor with dependencies injected
    
    public ProductDetails getProductDetails(String productId) {
        // Make parallel calls to different services
        CompletableFuture inventoryFuture = 
            CompletableFuture.supplyAsync(() -> inventoryService.getItem(productId));
            
        CompletableFuture priceFuture = 
            CompletableFuture.supplyAsync(() -> pricingService.getCurrentPrice(productId));
            
        CompletableFuture> reviewsFuture = 
            CompletableFuture.supplyAsync(() -> reviewService.getTopReviews(productId, 5));
        
        // Wait for all futures to complete
        CompletableFuture result = inventoryFuture
            .thenCombine(priceFuture, (item, price) -> new ProductDetails(item, price))
            .thenCombine(reviewsFuture, (details, reviews) -> {
                details.setReviews(reviews);
                return details;
            });
            
        return result.join(); // Wait for the combined result
    }
}

AWS Compute Options Comparison

When designing services on AWS, you need to choose the right compute option based on your requirements:

AWS Lambda

Best for: Stateless, event-driven, short-lived operations

Pros: Serverless, auto-scaling, pay-per-use, minimal operational overhead
Cons: Limited execution time (15 minutes max), cold start latency, limited memory (10GB max)
Use when: Building microservices, processing events, creating webhooks, running scheduled tasks

Amazon ECS (Elastic Container Service)

Best for: Containerized applications with medium-complexity orchestration needs

Pros: Container-based, good integration with AWS services, more control than Lambda
Cons: More operational overhead, more complex configuration
Use when: Running containerized applications, needing more control over environment, long-running processes

Amazon EC2 (Elastic Compute Cloud)

Best for: Applications requiring full control over compute resources

Pros: Maximum flexibility and control, wide range of instance types
Cons: Highest operational overhead, requires manual scaling and maintenance
Use when: Running legacy applications, needing specialized hardware, requiring full OS control

Guided Project

IMDb API - Service Design GILA

Introduction

In this activity, your group will read through a real design document from a team at Amazon, just as you would in a design review. After each section, you will discuss what has been communicated about the design, and what questions you still have. The goal by the end is to understand the design proposed by the document, how the document communicated that design effectively, and how we think about design documents as we review them.

General tips

It is common in code reviews to encounter new technical terms that you may be unfamiliar with. If you encounter this, first try to see if you can make an educated guess about the term using context clues. If you are blocked, reach out to an instructor.

If you have any additional questions when reading the design document which aren't covered in the document's FAQ, add your question to the digest for this lesson. If you are blocked, reach out to an instructor.