Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 1 of 256
`
`EXHIBIT M2
`
`
` This claim chart is meant to be illustrative for
`
`purposes of meeting Plaintiff's pleading obligations
`and should not be construed as binding or limiting.
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 2 of 256
`
`of
`
`network
`9. A
`interconnected,
`intelligent and improved
`web server computers
`with multi-modes of
`contact,
`multi-
`communications
`protocols, multi-user
`and parallel operational
`capabilities for use in a
`hospitality
`market
`comprising;
`
`Ameranth
`
`U.S. Patent No. 11,842,415
`
`Claim 9 Chart
`
`DoorDash has implemented a sophisticated network of interconnected web server
`computers that showcase intelligent, improved, and parallel operational capabilities
`tailored for the hospitality market. This network, in line with Claim 9 of the '415
`patent, employs multi-modes of contact and supports multiple communication
`protocols, ensuring robust and flexible interactions among consumers, merchants,
`and delivery personnel (Dashers). The system's strength lies in its multi-user
`environment, which is efficiently managed through a centralized data platform or
`master database.
`
`This central data platform is pivotal to DoorDash's operation, as it consolidates data
`from various sources—consumer interactions, transactional data, and real-time
`events from DoorDash's suite of applications. By integrating machine learning
`algorithms, the network can adapt and optimize its operations, enhancing the overall
`efficiency of the service. This adaptability is evident in the way DoorDash
`dynamically manages delivery routes, balancing demand from consumers with the
`supply of Dashers and inventory from merchants. The intelligence of the network
`allows for predictive modeling, which anticipates order readiness and optimizes
`delivery routes for efficiency and customer satisfaction.
`
`DoorDash's Vice President of Analytics and Data Science's insights reinforce the
`network's capability to collect comprehensive data, centralize it for accessibility, and
`utilize it for a 360-degree view of the marketplace—hallmarks of the interconnected
`web server computers described in Claim 9. This approach not only improves
`operational performance but also drives better consumer engagement and economic
`opportunity, thus aligning with the '415 patent's emphasis on an intelligent, data-
`driven network designed to meet the complex needs of the hospitality market.
`
`DoorDash develops, tests, integrates, uses, operates, manages, and maintains a
`‘parallel operational’ based network set of interconnected and improved “Intelligent
`Web Servers with multi modes of contact”, utilizing Machine Learning (ML) with
`parallel operational capabilities for multi-users, via multi-communications protocols
`while integrating with its “central data platform” (i.e. “master database”). This system
`meets all the limitations of the ‘415 claims, as is detailed below, to complete remotely
`initiated hospitality food and drink delivery and pick-up tasks triggered by and from
`consumers, produced by merchants (restaurants, etc.), and delivered by Dashers. The
`DoorDash Flywheel diagram, shown below, makes evident that the DoorDash
`operates in accordance with its overall series of linked services and via its “360-
`degree picture” central (“Flywheel") and technology platform framework:
`
`1
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 3 of 256
`
`This was confirmed on August 17, 2022, by DoorDash’s Vice President of Analytics
`and Data Science Jessica Lachs in an interview on “Leveraging Data to Delight
`Customers Despite a Challenging Supply Chain” (see Exh #98) in which she states:
`
`
`
`“And so for us, it’s really about collecting as much information as we can
`about all sides of the marketplace, bringing all of that data together into a
`central data platform, where all of that data is accessible no matter the
`source. Whether it is coming from our production systems, transactional data,
`whether it is event data in our apps, whether that’s the consumer app, the
`dasher app, the merchant app… whether it is coming from our CRM systems.
`All of that data needs to come in to one central place so that we can tie it
`together and use the insights together to create a 360 degree picture of what’s
`happening on our platform and off our platform so that we can use that
`information not just to provide accurate menus and inventory for consumers
`but also so we can send the right email communications to consumers, to
`dashers, so that we really have a full picture of what’s happening and can use
`that for personalization and to help all three sides of our marketplace really
`optimize that they are at their peak efficiency.”
`
`“So, for us, we want data to be easily accessible to all the different teams that
`need access to it. Analytics, being one of the largest customers of data at
`DoorDash, of course, but the way we think about our data models is really
`about increasing accessibility and consistency to that data. So, having all of
`our data in one central place and making sure that it is high in performance
`and so like query speeds are fast and that data models are thoughtful, so that
`it makes it a lot easier for data scientists, analysts, operators, product
`managers to be able to query the data that is needed and use the data in our
`production, in our production systems as well. So, we try to be thoughtful
`about how we structure our data models and how we ensure that all of the
`different production systems tie together into that central, as you mentioned,
`
`2
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 4 of 256
`
`that central data lake.”
`
`The DoorDash Life Cycle of a Delivery Order
`
`In the blog article from the DoorDash Engineering team titled “Next-Generation
`Optimization for Dasher Dispatch at DoorDash” (see Exh. 84) they state that the
`DoorDash platform “…powers an on-demand marketplace involving real-time order
`demand and dasher [(drivers)] supply. Consumers ask for goods to be delivered from
`a merchant to their location. To fulfill this demand, [DoorDash] present dashers with
`delivery routes, where they move between picking up orders at merchants and
`delivering them to consumers”, followed by the diagram below:
`
`
`
`Moreover, they assert the intelligence of their platform “Our dispatch system seeks
`high dasher efficiency and fulfillment quality by considering driving distance, time
`waiting for an order to be ready, delivery times as seen by the consumer, and more.
`Given incomplete information about the world, the system generates many
`predictions, such as when we expect an order to be ready for pickup, to model the
`real-world scenarios. With this data, the dispatch system generates future states for
`every possible matching and decides the best action to take, given our objectives of
`efficiency and quality.” See also Note 1 and Note 2 below.
`
`NOTE 1: To the extent, if any that DoorDash contends that it does not infringe, one
`or more of the ‘415 claim elements, they infringe under the Doctrine of Equivalents
`(DOE).
`
`NOTE 2: One or more of the 149 exhibits shown below, are incorporated into the
`support for their infringement of each of the elements the ‘415 claim elements.
`
`How DoorDash Work for Restaurants
`
`In the DoorDash Blog article “How Does DoorDash Work for Restaurants?” (See
`Exh 116), DoorDash states:
`
` “Restaurants can grow online with DoorDash by driving more sales on the
`app and through their own website, using Delivery, Pickup, and DashPass to
`
`3
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 5 of 256
`
`unlock the active (and hungry) customer base.”
`
`Regarding how customers place DoorDash Orders, the article states:
`
`“Restaurants can grow online with DoorDash by driving more sales on the
`app and through their own website, using Delivery, Pickup, and DashPass to
`unlock the active (and hungry) customer base.
`
`When customers are ready to place an order on Marketplace, they browse
`restaurants on the DoorDash app or website. Customers can search for their
`favorite establishments, or filter restaurants by cuisine, location, promotions
`and more. They enjoy the ease and convenience of browsing thousands of
`restaurants in a single app, as well as the ability to track orders and get
`restaurant-quality food anytime, anywhere.
`
`Customers can also place orders through Storefront, an online ordering
`system that gives restaurants direct, commission-free orders through their
`website, social media, and Google Search & Maps.
`
`Once the customer chooses a restaurant, they place their order, pay for it on
`the app or online, and receive an estimated delivery time. That's when
`restaurants receive the order via their chosen order protocol.
`
`Regarding how restaurants receive DoorDash Orders, the article states:
`
`“The order protocol is the way that restaurants receive orders from
`DoorDash. Restaurants can choose to receive orders on the device of their
`choice to maximize their off-premise efficiency. Storefront orders are
`processed in the same way as Marketplace orders. Restaurants have two
`options for their DoorDash order protocol.
`
`Option 1: Use the POS integration
`
`Maximize efficiency by integrating DoorDash with your point of sale (POS)
`system or aggregator. DoorDash integrates with leading POS and technology
`systems, including Square, Toast, Deliverect, ItsaCheckmate, Redcat and
`many more.
`
`This allows you to receive DoorDash orders directly to your POS system and
`then straight to your kitchen, which reduces the risk of human error.
`DoorDash also has an open API which enables partners to build integrations
`to manage their menu, store, and order data.
`
`Option 2: Use a tablet
`
`You can download the DoorDash Order Manager app, our all-in-one tool for
`receiving, organizing, and tracking pickup and delivery orders. DoorDash
`can also provide a tablet for you for a small weekly fee. Just order it by
`contacting support or choosing the option when signing up for DoorDash.
`
`4
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 6 of 256
`
`With the Order Manager app, restaurant operators can adjust prices and
`menu items in real time, including deactivating (and reactivating) specific
`items that are out of stock. The Order Manager app also helps restaurant
`managers coordinate with Dashers, prepare for large scheduled orders, pause
`orders when it gets too busy, and contact both the customer and DoorDash
`support.
`
`When a customer places a DoorDash order, you will receive a notification on
`the Order Manager app allowing you to quickly and efficiently process orders.
`Just be sure your tablet volume is on loud and the device is placed somewhere
`that is easily accessible by staff.”
`
`The article also discusses using the Business Manager App for iPhone or Android:
`
`Bonus: Business Manager App
`
`“Download the Business Manager App on the App Store or Google Play Store
`to manage your restaurant on the go. The Business Manager app makes it
`easy to track orders and review performance, all from your phone. Monitor a
`Dasher's location, access 24/7 support, mark items out of stock, update store
`hours, get analytics, and more from the app.”
`
`In the blog article by the DoorDash Engineering team title “Transforming MLOps at
`DoorDash with Machine Learning Workbench”, states how DoorDash has developed
`an internal Machine Learning (ML) Workbench to enhance data operations and
`support their data scientists, analysts, and AI/ML engineers. The importance of ML
`at DoorDash is emphasized, given its applications across the platform's ecosystem
`involving customers, Dashers, and merchants. The ML Workbench serves as a
`centralized hub for tasks in the machine learning lifecycle, including building,
`training, tuning, and deploying machine learning models. (See Exh. 121)
`
`DoorDash's ML Workbench streamlines the machine learning process by providing a
`space for data collection, organization, and use in ML algorithms. It was designed
`with user-centered principles, aiming to create a best-in-class internal tool that is
`functional, usable, aesthetically pleasing, and integrates well with DoorDash's
`internal tools ecosystem. The development strategy was iterative, focusing on
`understanding user pain points, designing solutions, running user tests, and
`optimizing for better velocity and productivity.
`
`Key components of the ML Workbench include front-end UI (Portal), Admin
`(Middleware), and Backend + 3rd Party Services. Through user research and
`interviews, DoorDash categorized users into admins, end users, and operators,
`tailoring the Workbench's features to their needs. Features such as model viewing,
`testing predictions, and model performance monitoring were added to streamline
`daily workflows and accelerate model development velocity.
`
`5
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 7 of 256
`
`
`
`The implementation of the ML Workbench has led to significant improvements in the
`efficiency and user experience of DoorDash's engineering and data science teams.
`The tool facilitated better observability of features and models, and the future vision
`includes diversifying adoption, improving feature and model observability, and
`continuing a user-centric development approach.
`
`This ML Workbench and its capabilities align well with Claim 9 of the patent, as it is
`an embodiment of an interconnected, intelligent web server network with multi-
`modes of contact, multi-communications protocols, and multi-user and parallel
`operational capabilities. The master database's role within this framework is also
`showcased, where it integrates with the network of web servers and is accessible via
`a database API, which intelligently learns, updates, and stores data. The Workbench's
`integration with various ML lifecycle stages and its emphasis on efficiency and
`reliability reflect the innovations described in Claim 9, particularly in the context of
`improving network efficiency and reliability.
`
`The accused instrumentality meets this limitation under the doctrine of equivalents
`because the accused instrumentality performs substantially the same function, in
`substantially the same way to achieve substantially the same result. For example,
`the Doctrine of Equivalents, even if the precise terminology used in the claim does
`not perfectly match the description provided, elements in DoorDash's network that
`perform substantially the same function, in substantially the same way, to achieve
`substantially the same result can be considered equivalent to the claim's elements.
`This doctrine allows for a broader interpretation, ensuring that innovations that are
`not identical in terminology but are equivalent in function and purpose are still
`protected under the claim. Therefore, DoorDash's network may be considered to
`meet the claim's limitations under the DOE, as it exhibits characteristics and
`functionalities equivalent to those outlined in the claim, even if the specific wording
`differs in the description.
`
`See Exh 1 - 149
`
`at least one network of
`said interconnected web
`server computers which
`
`DoorDash has created a robust distributed computing platform that consists of a
`network of interconnected and intelligent web servers, which can be accessed and
`controlled by system administrators through a web-based interface. This network
`
`6
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 8 of 256
`
`
`
`can be accessed and
`controlled by system
`administrators via
`a
`web-based interface;
`
`
`
`enables multi-user engagement and supports multi-modes of contact through the use
`of hardware, software, and networking services, to offer an industry leading online
`hospitality system.
`
`The interconnected web server system includes a suite of interfaces such as websites,
`mobile apps, and APIs, underpinned by a backend-for-frontend architecture that
`facilitates communication between the client and server. This network harnesses
`popular technologies like Next.js, Express.js, and Node.js to serve content efficiently
`to various client devices through the internet, with a focus on performance, flexibility,
`and user experience.
`
`DoorDash's web servers operate on powerful clusters to handle the extensive scale of
`their operations, ensuring that content is served swiftly and reliably to meet the
`demands of consumers, merchants, and Dashers. The system's infrastructure is
`designed to scale dynamically, adjusting to the number of client requests by utilizing
`server clusters, which are assigned unique IP addresses for seamless communication
`over the internet.
`
`The web-based interface for system administrators is central to DoorDash's
`operational model, allowing for the orchestration of data and application processes
`across the network. This interface is essential for the management of the intricate
`DoorDash ecosystem, enabling administrators to monitor, control, and optimize the
`system's performance and reliability.
`
`The interconnectivity of DoorDash's web server network is exemplified by its use of
`server-side rendering and migration to a microservices architecture, enhancing the
`system's reliability and scalability. The transition to this architecture involved
`adopting new programming languages and technologies, such as Kotlin and the Java
`Virtual Machine, to improve the system's fault tolerance and efficiency.
`
`DoorDash's adoption of a microservices architecture, with a backend-for-frontend
`layer, reflects the patent claim's emphasis on a networked web server system that can
`be accessed and controlled via a web-based interface. This architecture has allowed
`DoorDash to compartmentalize their application into domain-specific services,
`leading to reduced errors and latency, and enabling the system to deliver a responsive
`and reliable service to its users.
`
`As stated above, as to the ‘one network of said interconnected web server computers’,
`and confirmed below, DoorDash develops, tests, integrates, uses, operates, manages,
`and maintains a “distributed computing” platform of clustered set of interconnected
`and vastly improved “Intelligent Web Servers with multi modes of contact”.
`DoorDash uses a combination of web server hardware, software, and networking
`services to create a very powerful and effective online web-based hospitality system,
`as confirmed below.
`
`The DoorDash web server system includes a website, mobile website, APIs, mobile
`apps (iOS and Android), and backend-for-frontend (BFF) architecture and
`functionality. Their interconnected web servers, as is shown herein, is a DoorDash
`engineered custom developed set of interconnected web servers while including
`
`7
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 9 of 256
`
`several well-known and widely used web server-based technologies.
`
`A webserver serves content (images, text, menu, video, audio, video stream, etc.) over
`the internet (or network) to a calling device (client) that runs on computer hardware.
`There can be one or more calling clients at any given moment. The computer
`hardware that the webserver runs on can be any device with a network connection
`(laptop, server computer, mobile device, etc.).
`
`To serve content, a webserver listens on a network port (virtual point where network
`connections start and end) for a request from a client (browser, mobile app, webapp,
`desktop app, etc.) sent via a networking communication protocol (i.e., HTTP or
`HTTPS). The webserver interprets and processes that request and returns a response
`to the client with the resources requested (text, images, menus, code, etc.). Depending
`on the scale of the webserver running web application(s), for example the DoorDash
`system, more powerful linked computer servers or sets/clusters of servers will be used
`to run a bigger system.
`
`Each web server has an IP address associated with it that allows it to communicate
`with other computers over the internet. When a user types in a name of a website in
`the browser, such as DoorDash.com, the Domain Name System (DNS) finds the
`correct IP Address of that domain name and directs the user accordingly (see Exh.
`83). Using the “ping” command from any Windows or MacOS PC on DoorDash.com
`returns the IP address of 104.18.29.209, as screen in this screenshot:
`
`
`
`8
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 10 of 256
`
`In the blog article “Improving Web Page Performance at DoorDash Through Server-
`Side Rendering with Next.JS” (see Exh. 1) by the DoorDash Engineering Team, they
`affirm multiple facts regarding the DoorDash system including the use of a webserver
`and how it works. Specifically, they state that that they needed to upgrade the user
`experience for desktop and mobile and employ Google’s web metrics as a benchmark
`for creating a faster web service. Furthermore, they state that they use Next.js,
`Express.js, Node.js as part of their web server system, technologies which are very
`popular today with developers and are in fact web server (backend) technologies.
`Lastly, and more importantly, they state that their system needed more “flexibility”
`from the web server hosting and therefore they decided to build and implement their
`own custom web server using next.js and express.js. The article states the following:
`
`“The DoorDash app was running on a client-side system prone to loading
`issues, poor SEO, and other issues. By moving to server-side rendering, we
`hoped that we could upgrade a number of key elements, including:
`
`Enhancing the user experience: We wanted to improve the user experience by
`shortening page-load times. This aligns with the recent introduction of
`Google’s web metrics that favor fast, lightweight pages on modest mobile
`devices. These metrics have significant influence on the page rank assigned
`by Google.
`
`Enabling Bundle Size Optimization: Our existing client-side rendered single-
`page app (CSR, SPA) was becoming difficult to optimize because the size of
`the JavaScript and other resource bundles had become bloated.
`
`Improving SEO: We set out to deliver optimal SEO metadata using server-
`side rendered content. Whenever possible, it is better to deliver fully formed
`web content to search engines rather than waiting for client-side JavaScript
`to render the content. One approach: Move API calls from the client browser
`(north-south) to the server-side (east-west), where performance typically is
`better than on a user’s device.”
`
`“Many engineers at DoorDash are huge fans of the Next.js team and Vercel.
`Vercel’s infrastructure was built for Next.js, providing both an amazing
`developer experience and a hosting infrastructure that make working with
`Next.js easy and maximally optimized.”
`
`“At DoorDash, however, we needed a little more flexibility and customization
`than Vercel could offer when it comes to how we deploy, build, and host our
`apps. We opted instead for the custom-server approach to serving pages via
`Next.js because it provided us more flexibility in how we hosted our app
`within our existing Kubernetes infrastructure.”
`
`“Our custom server is built with Express.js and leverages our in-house
`JavaScript server toolkit, which provides out-of-the-box functionality like
`logging and metrics collection.”
`
`“Before rolling out our new service to production, we needed to know how
`much traffic it could support and what resources it required… After an initial
`9
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 11 of 256
`
`audit we saw that not all cores were being utilized to spread the processing
`load. As a result we used Node.js’s cluster API to make use of all the pod’s
`cores, which quadrupled the pod’s request capacity”.
`
`Node.js “…is an open-source, cross-platform runtime environment that allows
`developers to create all kinds of server-side tools and applications in JavaScript. The
`runtime is intended for use outside of a browser context i.e., running directly on a
`computer or server OS (see Ex. 2). (For a simple example of how to create a server
`to start listening to HTTP requests see Ex. 11).
`
`Express.js “… is a back-end web application framework for Node.js. It is designed
`for building web applications and APIs. It has been called the de facto standard server
`framework for Node.js” (see Ex. 3).
`
`Next.js is a server rendered React (JavaScript) framework used to create high
`performing web applications and has become very popular in the tech world. “Next.js
`handles the tooling and configuration needed for React, and provides additional
`structure, features, and optimizations for your application. Next.js is a JavaScript
`framework that enables you to build superfast and extremely user-friendly static
`websites, as well as web applications using React. This feature allows Next.js to build
`hybrid applications that contain both server-side rendered and statically generated
`pages” (see Ex. 4.).
`
`Furthermore, in 2019, DoorDash rebuilt their web UI using the React and Next.js
`frameworks. At that time, they also implemented server-side rendering (a method of
`rendering web applications on the server and serving a static HTML page loaded with
`data specific to the requested page to the user). This helped to improve the
`performance of the overall web application by shortening page-load times, improve
`bundle size optimizations, and improving SEO (see Exh. 27).
`
`The original DoorDash platform was originally a monolithic application written in
`Python using the Django web framework with a PostgreSQL database. As the
`platform grew, they started to have problems with reliability and scaling. Around
`2018 they instituted a code freeze and began migrating to microservices. At this time,
`they also migrated to the Kotlin language, and their services now run on the java
`virtual machine (JVM) (see Exh 20, 21, 22, 40).
`
`DoorDash was able to improve the efficiency and reliability of their platform using a
`microservices architecture. By breaking up their application into domain-specific
`parts they were able to reduce errors and latency. They state in the article “Future-
`proofing: How DoorDash Transitioned from a Code Monolith to a Microservice
`Architecture” (see Exh. 20) that “… final design for our new microservice
`architecture consisted of five different layers, ranging from the user experience to the
`core infrastructure. Each layer provides functionality to the upper layer and
`leverages the functionality exposed by the lower layer [as shown below]”:
`
`10
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 12 of 256
`
`
`
`These layers include (see Exh 20):
`
`
`
`“Frontend layer: Provides frontend systems (like the DoorDash mobile app,
`Dasher web app, etc.) for the interaction with consumers, merchants, and
`Dashers that are built on top of different frontend platforms.
`
`BFF layer: The frontend layer is decoupled from the backend layer via BFFs.
`The BFF layer provides functionality to the frontend by orchestrating the
`interaction with multiple backend services while hiding the underlying
`backend architecture.
`
`Backend Layer: Provides the core functionality that powers the business logic
`(order cart service, feed service, delivery service, etc.).
`
`Platform layer: Provides common functionality that is leveraged by other
`backend services (identity service, communication service, etc.).
`
`11
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 13 of 256
`
`Infrastructure layer: Provides the infrastructural components that are
`required to build the site (databases, message brokers, etc.) and lays the
`foundation to abstract the system from the underlying environment (cloud
`service provider).”
`
`In this, DoorDash’s new architecture they introduced the backend-for-frontend (BFF)
`“…an application connecting the consumer-facing client and the services providing
`general purpose APIs. Client requests go to the BFF, which then orchestrates the
`aggregation of information needed by the client”. The BFF is a software architecture
`pattern (see Exh 40) used by microservices which “…shifted from thick-client
`applications to interfaces delivered via the web, a trend that has also enabled the
`growth of SAAS-based solutions in general”. As such BFF can be considered as
`“…the user-facing application as being two components - a client-side application
`living outside your perimeter, and a server-side component (the BFF) inside your
`perimeter”. The perimeter of the BFF is the webserver.
`
`In the blog article by the DoorDash engineering team Platform Optimization Through
`Better API Design (see Exh. 22) they state in the introduction:
`
`“As DoorDash migrated from a monolithic codebase to a microservices
`architecture, we found an opportunity to refine our API design. Beyond simple
`functionality, we determined best practices in making APIs that help our
`applications load quickly, use minimal storage, and, most importantly, avoid
`failures.”
`
`“APIs, the connective tissue of a software platform, can offer performance
`improvements when properly designed. At DoorDash, the APIs relay frontend
`client requests to backend services and provide the information that users see
`in our apps, such as the estimated time when a food order will be delivered.
`If the APIs perform at maximum efficiency, client requests and responses all
`process more quickly” (see Exh 20, 21, 40).
`
`In their new architecture they introduced the backend-for-frontend (BFF) “… an
`application connecting the consumer-facing client and the services providing general
`purpose APIs. Client requests go to the BFF, which then orchestrates the aggregation
`of information needed by the client”. The BFF is a software architecture pattern (see
`Exh 40) used by microservices which “…shifted from thick-client applications to
`interfaces delivered via the web, a trend that has also enabled the growth of SAAS-
`based solutions in general”. As such BFF can be considered as “…the user-facing
`application as being two components – a client-side application living outside your
`perimeter, and a server-side component (the BFF) inside your perimeter”. The
`perimeter of the BFF is the webserver.
`
`As shown “…in the diagram below …when the BFF receives the order details
`request, it orchestrates the calls to the consumer service, order service, and delivery
`service, ultimately assembling the response details into a consolidated order
`detail response. Building APIs using domain-specific services, orchestrated by the
`BFF, makes it easier to understand which RPCs are called and how they are executed”
`(see Exh. 41).
`
`12
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 14 of 256
`
`
`
`BFF is the core service that permits their large system to be pieced into various
`backend sub-systems (microservices) for performance improvements and easier
`maintainability. They go on to state that:
`
`“At DoorDash, our APIs primarily support information on food orders,
`whether that’s an order placed by a consumer and sent to a restaurant, a
`delivery request sent to a Dasher, or a Dasher’s progress in bringing a food
`order to a consumer. For example, two main endpoints, order detail and order
`delivery status, populate our order tracking page, [as] shown in [the figure
`below]”
`
`13
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 15 of 256
`
`
`
`“When we redesigned the Reorder endpoint, we wrote the Reorder API so it
`would read the order information it needs to create the new cart instead of
`passing the large order data over the network to create the new cart, as shown
`[below]…[here] in our redesigned order flow, we reduce network traffic by
`writing the Reorder API so that it reads the order detail and creates the new
`cart, simplifying its role…. The client only needs metadata for the new cart
`from the Reorder endpoint, so we only return a cart summary response to the
`client instead of the whole cart. Compared to the previous flow, shown in
`Figure 4, we not only eliminate the request to call GET order cart from the
`client, but also make both the request and response very light.”
`
`Fault Tolerance with RPC Fallbacks in DoorDash’s Microservices
`
`
`
`14
`
`
`
`
`
`

`

`Case 2:23-cv-02165-WSH Document 1-15 Filed 12/22/23 Page 16 of 256
`
`In the blog article “Improving Fault Tolerance with RPC Fallbacks in DoorDash’s
`Microservices” by the DoorDash Engineering team (see Exh 119), they stat