Building a Coherent Architecture

Bringing It Together 🧭

In this final lesson, you will turn the connected-cloud decisions into one coherent architecture for the family-booking application. The family-booking application is Tutor Bright’s booking application: parents book lessons, pay by card, and upload photos of completed lesson work. Rather than defend isolated technology choices, you will trace one request end to end and explain a recommendation a non-technical founder can evaluate. In this lesson, you will learn to: Trace a browser request through DNS, cached content, load balancing, application compute, and the data store Make and justify five connected choices: service model, compute, storage, database, and integration style Explain region, resilience targets, cost drivers, and trade-offs in stakeholder-friendly language

Trace the Request Path Out Loud 🛣️

Before you recommend anything, walk the path a single user request takes. Say it aloud, in order, because that order tells you which decisions you still owe an answer on. A parent enters the site’s domain name in a browser. First, the browser uses the Domain Name System (DNS) to resolve that name to DNS records, commonly including an IP address. Next, static images and other cacheable files may be served by a content delivery network (CDN) from an edge location near the user. On a cache hit, the edge can serve the file without contacting the origin region; on a cache miss, it may retrieve the file from the origin. What remains hits a load balancer, which spreads incoming requests across the servers that are running and skips any that are unhealthy. Behind that, your application code runs on compute, whichever form you chose. Finally, the code reads and writes booking records in the database . That gives you five stops to inspect, in order: DNS resolution Cached content at the CDN edge The load balancer Application compute The data store Every design question should map to one or more of these stops. Scenario: Milo, a cloud architect, is reviewing the family-booking application’s monitoring data with Natalie, its product lead. Natalie: The founder wants to know why the site felt slow at seven o’clock. Can you give me one sentence? Milo: The monitoring data shows normal DNS and CDN behaviour, while both application instances reached their concurrency limit, so the delay is at the compute layer. Natalie: So it was further in. Milo: Yes. We should add or autoscale healthy application instances, then verify that the database is not the next bottleneck. Natalie: That I can repeat back to her. Notice what Milo did: he didn't guess. He walked the same five stops in order and stopped at the one that explained the symptom.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Make the Five Choices in Order 🧩

With the path in your head, make the design choices in a fixed sequence. Doing them in order stops you defending a database decision before you've settled who runs the servers.

Start with the service model. For a small team and a straightforward web application, a managed platform (Platform as a Service) is usually the honest answer: the provider handles the servers, the operating system, and the patching underneath, and your team ships the application. Say it that plainly and the room understands what you've just bought.

Then compute. The platform choice largely settles this, but you still say how it scales: more instances during the evening peak, fewer overnight. Then storage, split by what the data actually is. Uploaded lesson photos belong in object storage, which stores whole files and can serve them to browsers. Storage tiers are price levels: keep frequently used photos in a standard tier and move older, rarely used photos to a cheaper tier. Because we are using a managed database, the provider handles its underlying disks; we do not choose block storage ourselves. Then the database itself. If the application takes payments or bookings, where a group of changes must all succeed or all fail together, you want a managed relational database. Finally, choose the integration style. Keep the checkout request synchronous only for the immediate response it needs, such as whether a payment provider accepted an authorisation request. Handle later payment updates and confirmation delivery asynchronously: enqueue an email job, or publish an event to a topic that consumers receive, so a slow email provider does not hold up checkout. Process provider webhooks—HTTP callbacks a provider sends when a payment outcome changes—idempotently, so a retry does not create duplicate work, because final outcomes can arrive later or be retried.

Five choices, in that order, and you have a design. Write them down as five short sentences before you write anything longer.

Building a Coherent Architecture

Bringing It Together 🧭

Trace the Request Path Out Loud 🛣️

Join the 1M+ learners on CodeSignal

Make the Five Choices in Order 🧩

Present It So a Non-Technical Stakeholder Can Sign It 🤝