Technology Mapping &
INFO 153B/253B Backend Web Architecture
Week 12: From Patterns to Decisions
Spring 2026 | UC Berkeley School of Information
Last week was the "aha" moment — students saw that their 253B tech stack maps to universal building blocks. This week we go deeper in two ways: first, how do you choose WHICH technology implements each building block? And second, what DRIVES the decision of which building blocks you need in the first place? By the end, they'll have the complete system design framework: External entities tell you what you need, building blocks define the architecture, and technology mapping picks the tools.
Today's Agenda
Part 1: Technology Mapping — From building blocks to real toolsPart 2: External Entities — The forces that shape every systemDemo: Design a photo sharing platform (all 7 building blocks)Exploration: Design a food delivery app
The complete framework: External Entities → Building Blocks → Technologies
Frame the two halves: Part 1 is the "right side" of the framework — once you know which building blocks you need, how do you pick technologies? Part 2 is the "left side" — what drives the decision of which building blocks to use? Together with last week's building block knowledge, they'll have the end-to-end system design process.
Last Week's Foundation
Task Blocks
Service
Worker
Storage Blocks
Key Value Store
Queue
Relational DB
File Store
Vector Database
7 building blocks compose every system. But two questions remain:
How do you choose which technology implements each block?
What drives the decision of which blocks to use?
Quick recap — don't dwell. They know the 7 blocks. The two open questions set up today's two sections perfectly. Part 1 answers question 1 (technology mapping). Part 2 answers question 2 (external entities).
Part 1
Technology Mapping
This section bridges building blocks to actual technology decisions. The key insight: building blocks are patterns, technologies are implementations. One technology can serve multiple patterns, and that creates both opportunity and risk.
Pattern-First Technology Choices
Code Writer
"I need to use Redis because everyone uses Redis"
System Thinker
"I need Key Value Store capabilities — Redis fits this pattern"
System thinkers start with the pattern , then evaluate technologies
This prevents hype-driven decisions and enables objective comparison
When a new technology appears, ask: "Which building block does this implement?"
This is the core mindset shift for technology selection. Instead of starting with a technology ("let's use Kafka"), start with the pattern ("we need ordered message processing — that's a Queue"). Then evaluate: Kafka, RabbitMQ, SQS — which one fits our specific constraints? This approach also makes you future-proof: when some hot new technology comes out, you can immediately evaluate it by asking which building block it implements and what trade-offs it makes.
Building Blocks → Technologies
Building Block
Technology Options
253B Choice
Service REST (Flask, FastAPI, Express), GraphQL, gRPC, Serverless (Lambda)
Flask
Worker Celery, rq, Bull, Sidekiq, AWS SQS, Airflow
rq
Key Value Store Redis, Memcached, DynamoDB, ElastiCache
—
Queue Kafka, RabbitMQ, SQS, Redis Lists, Google Pub/Sub
Redis Queue
Relational DB PostgreSQL, MySQL, SQLite, Aurora, Cloud SQL
PostgreSQL
File Store AWS S3, Google Cloud Storage, Azure Blob, MinIO
—
Vector Database Pinecone, Weaviate, pgvector, ChromaDB, Qdrant
—
Same patterns, many implementations. The building block stays constant.
Walk through this table. Point out that every row has multiple technology options — that's the point. The building block is the pattern; the technologies are interchangeable implementations. They chose Flask for Service, but FastAPI, Express, or Django would implement the same pattern. They chose PostgreSQL for Relational DB, but MySQL or Aurora would work too. The pattern doesn't care about the technology. This is why learning building blocks is more valuable than learning any single technology.
One Technology, Multiple Building Blocks
A single technology can implement more than one building block pattern.
Redis
Key Value Store Queue
PostgreSQL
Relational DB Vector DB (pgvector)
This is powerful and dangerous — it creates the Replacement Trap
This is one of the most important insights in technology mapping. Redis is both a Key Value Store (caching, sessions) AND a Queue (pub/sub, lists). PostgreSQL is both a Relational Database AND a Vector Database with pgvector. This is convenient — fewer tools to manage. But it's also dangerous, because when people say "let's replace Redis" they're conflating two completely different building blocks. That's the Replacement Trap, which we'll cover next.
The Replacement Trap
Without Building Block Clarity
"We need to replace Redis"
Must find one technology that does caching AND queuing
Complex evaluation, limited options, unnecessary coupling
With Building Block Clarity
"We need a new Key Value Store for caching AND a new Queue for messaging"
Memcached for caching + SQS for queuing
Simpler, more focused, easier to optimize
Building block clarity turns a confusing migration into two simple decisions.
This happens all the time in industry. A team uses Redis for both caching and job queuing. They decide to migrate off Redis. Without building block clarity, they look for one tool that does everything Redis does — which is hard to find and probably over-engineered. With clarity, they realize they actually have TWO separate requirements: a Key Value Store for caching (Memcached is perfect — simpler, cheaper) and a Queue for messaging (SQS is purpose-built). Two simple decisions instead of one impossible one. This is why we separated Redis from "Key Value Store" in last week's slides — they're different building blocks that happen to share a technology.
Choosing Technologies Systematically
Identify ALL building block patterns needed "We need this for caching AND queuing" — that's 2 patterns Single vs specialized technologies One tool for both patterns? Or focused tools for each? Evaluate performance needs Latency, throughput, consistency — for EACH pattern Consider operational complexity Team expertise, maintenance burden, monitoring Evaluate cost Infrastructure, licensing, operational overhead Plan for evolution Can patterns be separated later? What are the migration paths?
Walk through with a concrete example. "We need caching and job queuing. Step 1: That's Key Value Store + Queue — two building blocks. Step 2: Redis can do both, or we could use Memcached + RabbitMQ. Step 3: Caching needs sub-millisecond, queuing can tolerate seconds. Step 4: Team already knows Redis. Step 5: One Redis instance is cheaper than two separate services. Step 6: If queuing needs grow, we can split to SQS later. Decision: Start with Redis for both, plan to split if needed." This is how senior engineers think — systematic, not gut feeling.
Why We Chose the 253B Stack
Building Block
We Chose
Why (Pattern Reasoning)
Service Flask
Simple REST, Python-native, minimal boilerplate
Worker rq
Lightweight, Python-native, Redis-backed
Queue Redis Queue
Simple FIFO, integrates with rq, good for learning
Relational DB PostgreSQL
Industry standard, ACID, rich features, free
Every choice was driven by the pattern requirement , then filtered by constraints
Different constraints (performance, team, scale) → different technologies, same patterns
This makes the pattern-first approach concrete using decisions they've already experienced. We didn't say "let's use Flask because it's popular." We said "we need a Service for REST APIs" (pattern), then chose Flask because it's Python-native, minimal, and great for learning (constraints). A production team at Netflix might choose the same Service pattern but pick gRPC for performance. Different technology, same building block. This is why understanding patterns is more valuable than memorizing any single technology.
Common Technology Selection Mistakes
Technology-first thinking "Let's use Kubernetes!" — Before asking what building blocks you actually need.
Hype-driven decisions Choosing Kafka because it's trending when a simple Redis Queue would do.
Over-engineering Kubernetes for a single Service. Kafka for 100 messages/day.
Under-engineering One PostgreSQL database for everything — caching, queuing, file metadata, search.
Pattern-driven thinking prevents all of these. Start with requirements, not tools.
These are real mistakes that cost companies millions. Technology-first thinking skips the most important step — understanding what you actually need. Hype-driven decisions ignore operational reality (Kafka is amazing, but do you need a distributed streaming platform for 100 messages a day?). Over-engineering creates complexity your team can't maintain. Under-engineering creates technical debt that requires expensive rewrites. Building block thinking prevents all of these because you start with "what pattern do I need?" not "what technology is cool?"
Patterns Outlast Technologies
Building Block
2005
2015
2025
Pattern
Service CGI / Servlets
REST / Express
GraphQL / gRPC
Request → Response
Key Value Store Memcached
Redis
DynamoDB
Key → Value
Queue JMS
RabbitMQ
Kafka / Pulsar
FIFO messaging
Technologies change every ~5 years. Patterns stay for decades .
When the next new tool appears, ask: "Which building block pattern does this implement?"
You'll be able to evaluate it instantly.
This reinforces last week's message with concrete evidence. CGI, Servlets, REST, GraphQL — all different technologies, all implementing the same Service pattern: receive a request, process it, return a response. The interface hasn't changed in 30 years. Memcached, Redis, DynamoDB — all Key Value Stores: give a key, get a value. When the next hot technology comes out in 2027, they'll be able to evaluate it immediately by asking "which building block does this implement and what are its trade-offs?" That's career-level value.
Pattern → Technology in Action
Business Need
Building Block
Technology Options
Fast user session storage
Key Value Store
Redis (in-memory) / DynamoDB (managed) / localStorage (client)
Background email sending
Worker
Celery (Python) / SQS+Lambda (cloud) / rq (simple)
API for mobile app
Service
REST (simple) / GraphQL (flexible) / gRPC (performance)
"Find similar products"
Vector Database
Pinecone (managed) / pgvector (familiar) / Weaviate (open-source)
Same pattern, different technologies based on constraints
Requirements first → Pattern → Technology filtered by team, cost, scale
Walk through each row. For session storage: the pattern is always Key Value Store, but Redis is great for in-memory speed, DynamoDB for managed simplicity, localStorage if you want client-side. For email: Worker pattern, but Celery for Python shops, SQS+Lambda for AWS-native teams, rq for simplicity. The business need drives the pattern; the constraints drive the technology choice within that pattern. This is exactly how senior engineers and architects think.
Technology Mapping: Key Insights
Pattern first, technology second — alwaysOne technology can serve multiple building blocks — be aware of thisThe Replacement Trap — building block clarity prevents confused migrationsUse the 6-step framework — systematic decisions, not gut feelingsTechnologies change; patterns don't — invest in pattern knowledge
You now know HOW to pick technologies.
Quick recap before switching to Part 2. They now have the right side of the framework — given a building block, how to pick a technology. But the bigger question is: what tells you which building blocks you need in the first place? That's external entities.
Part 2
External Entities: The Forces That Shape Systems
This is the missing piece. Building blocks are the tools. External entities are the job requirements that tell you which tools you need. After this section, they'll have the complete framework: external entities drive requirements, requirements determine building blocks, building blocks guide technology choices.
The Missing Piece
You know the 7 building blocks. You know how to map them to technologies.
But what tells you WHICH building blocks to use?
Building blocks are your tools
External entities are the job requirements that tell you which tools you need
You don't implement external entities — you respond to them
This is a perspective shift. Building blocks are internal — you choose and implement them. External entities are forces OUTSIDE your system that impose requirements on you. You can't control them; you can only design your system to respond to them. A user expects sub-second responses — that's not your choice, it's their expectation. Stripe's API has rate limits — that's not your design, it's their constraint. Midnight happens whether your backup system is ready or not — that's physics. These forces DRIVE your building block decisions.
The 3 External Entities
User
Human interactions
External Service
Third-party APIs
Time
Scheduled tasks
Every system responds to at least one, usually all three.
System thinkers analyze external entities first , then choose building blocks.
Introduce all three at once so they see the complete picture. User is the human (or system, or AI agent) that initiates interactions. External Service is any third-party dependency you don't control. Time is the relentless force that triggers scheduled work. Every architectural decision traces back to satisfying requirements from one of these three entities. The key insight: analyze entities FIRST, then choose building blocks. Not the other way around.
User The Human Force
Response time: Users expect <200ms for UI, <3s for heavy operationsReal-time needs: Instant messaging, live updates, notificationsScale patterns: Peak hours, concurrent users, viral growthContent types: Text, images, videos, documents they create and consume
253B connection: Every HTTP request to your Flask API is driven by the User entity.
User expectations drove your Service + Worker split in Week 8
User data needs drove your Relational Database choice in Week 7
The User entity is the most intuitive. Students already design for users — they just haven't formalized it. When they moved slow notification sending to a background worker in Week 8, that was responding to User entity requirements: users expect fast API responses. When they chose PostgreSQL with relationships for tasks and categories, that was responding to User entity data requirements. Make it concrete: "Your users won't wait 10 seconds for a response. That's a User entity requirement. It drove your decision to use Workers for heavy processing." Also mention: in the AI era, "User" includes AI agents calling your API — same patterns, same response time expectations.
External Service The Integration Force
Failure patterns: Services go down, rate limits hit, timeouts occurPerformance variability: Response times fluctuate unpredictablyData requirements: Authentication, transformation, error handlingCost implications: Per-call pricing, batch optimization
Real-world examples: Stripe (payments), SendGrid (email), OpenAI/Claude (AI), Twilio (SMS)
External Services are unreliable by nature — they will fail
This drives the Worker + Queue pattern for resilient integration
Rate limits drive Key Value Store caching to reduce API calls
External Services are forces you don't control. Stripe's API might be down. OpenAI might throttle your requests. SendGrid might take 5 seconds to respond. You must design for this reality. This is why the Worker + Queue pattern is so fundamental — it lets you retry failed calls, handle rate limits, and process integrations in the background without blocking your users. If their group projects integrate with any external API, they need to think about: what happens when it fails? What happens when it's slow? What happens when you hit rate limits? Those questions drive building block choices.
Time The Relentless Force
Scheduled tasks: Daily reports, weekly cleanups, monthly billingRecurring automation: Backups, monitoring, data syncExpiring data: Session tokens, temporary files, cache invalidationBusiness cycles: Peak hours, seasonal patterns, deadlines
253B connection: Assignment 2's due date reminders are driven by the Time entity.
Time is the only entity that's truly external — it's physics
Midnight happens whether your system is ready or not
Time requirements drive Worker scheduling and automation patterns
Time is unique among the three entities — it doesn't evolve and it doesn't negotiate. Users can be patient. External services can be swapped. But midnight happens on schedule, tokens expire on time, and billing cycles close regardless. Time drives Worker + scheduling patterns: cron jobs, recurring tasks, automated backups. In Assignment 2, the "send reminder if due within 24 hours" feature is entirely driven by the Time entity — a temporal condition triggers a Worker task. Point out the philosophical depth: Time is the only entity that exists completely independently of your system and the entire tech industry.
How Entities Drive Building Block Selection
Requirement
Driven By
Building Block(s)
Fast page loads
User Service + Key Value Store (caching)
Retry failed API calls
External Service Worker + Queue (retry pattern)
Daily sales report
Time Worker (scheduled)
User uploads photos
User Service + File Store
Reduce Stripe API calls
External Service Key Value Store (cache results)
Expire session tokens
Time Key Value Store (TTL)
This table is the bridge between entities and building blocks. Walk through a few rows. "Users want fast page loads — that's a User entity requirement. To satisfy it, you need a Service (to handle the request) and a Key Value Store (to cache frequently accessed data so you don't hit the database every time)." "Your payment provider goes down — that's an External Service reality. To handle it, you need a Queue (to hold the failed job) and a Worker (to retry it later)." Each row shows the systematic chain: entity → requirement → building block. This is how system thinkers design.
The Complete System Design Framework
User
External Service
Time drive requirements ↓Service
Worker
KV Store
Queue
Relational DB
File Store
Vector DB implemented by ↓Flask • rq • Redis • PostgreSQL • S3 • Pinecone • ...
Entities → Building Blocks → Technologies
This is THE slide. The complete framework in one view. External entities at the top drive requirements. Building blocks in the middle define architecture. Technologies at the bottom implement the building blocks. This is the sequence system thinkers follow every time: What entities am I responding to? What building blocks satisfy their requirements? What technologies best implement those building blocks given my constraints? They've now learned all three layers over Weeks 11 and 12. This is genuinely the framework that senior architects use at companies like Google, Netflix, and Amazon.
External Entities in the AI Era
User Entity Evolves
2010s: Humans via browsers2020s: Systems via APIsNow: AI agents calling your Service
The pattern stays the same: auth, rate limits, responses
External Service Evolves
2010s: Stripe, Twilio2020s: OpenAI, Claude APIsFuture: Autonomous agent services
The pattern stays the same: retry, rate limit, cache
WHO is on the other side changes. The interface patterns never do .
This is a powerful career message. The User entity used to be humans clicking buttons. Now it includes AI agents calling your API — ChatGPT plugins, GitHub Copilot, automation agents. But they still need authentication, rate limiting, and structured responses. The External Service entity used to be Stripe and Twilio. Now it includes OpenAI and Claude APIs. But you still need retry logic, rate limit handling, and cost optimization. The patterns are identical. If they understand building blocks and external entities, they can design systems that work regardless of whether the user is human or AI, regardless of whether the external service is traditional or AI-powered. That's future-proof thinking.
Why This Matters for Your Career
Your Role
How This Helps
Product Manager Speak the same language as your engineering team. Understand why "just add this feature" might need a new building block.
Designer / Researcher Understand what's technically feasible. "Real-time updates" means a different architecture than "daily reports."
Software Engineer Justify technical decisions with requirements, not preference. Stand out in design interviews.
Data Scientist / Analyst Understand where your data lives and why. Know what's easy to query vs what needs a pipeline.
Anyone in Tech Users, services, and timelines are how business stakeholders already think. This framework bridges tech and business.
You don't need to build these systems to benefit from understanding them
The people who understand how systems work make better decisions in every role
This isn't just for engineers. Product managers who understand building blocks can have more productive conversations with engineering — they know why adding "real-time notifications" is a bigger ask than "daily email summary" (it requires a Queue + Worker + push service integration vs just a scheduled Worker). Designers who understand system constraints make more feasible design decisions. Data scientists who understand where data lives (Relational DB vs Key Value Store vs File Store) can reason about what's queryable and what needs a pipeline. And for engineers: in design interviews, starting with external entities before building blocks is what separates senior from junior candidates. This framework helps everyone who works around technology — not just those who write code.
Key Takeaways
Pattern first, technology second — building blocks guide technology choicesWatch for the Replacement Trap — one technology can serve multiple patterns3 external entities drive all requirements — User, External Service, TimeThe complete framework: Entities → Building Blocks → TechnologiesThis thinking is AI-proof — patterns stay constant regardless of who's on the other end
You now have the complete system design vocabulary :
This is the culmination of Weeks 11 and 12. They now have every piece of the system design framework: external entities to analyze requirements, building blocks to define architecture, and technology mapping to choose tools. This is genuinely the framework used by senior architects at top companies. Next week they'll apply it to real-world case studies. For now, let this sink in — they've gained a mental model that will serve them for their entire career.
Demo
Designing a Photo Sharing Platform
Transition to the demo. This time you're designing a system from scratch using ALL 7 building blocks. Start with external entities, derive the building blocks, then mention which technologies you'd pick. This demonstrates the complete framework end-to-end. Use the whiteboard — draw it live.
Demo: Photo Sharing Platform
Let's design Instagram-style photo sharing using the complete framework...
Step 1: Identify External Entities
User
Upload photos
External Service
Push notifications
Time
Daily digest emails
(Live demo — draw this step by step on the board)
LIVE DEMO: Start here. Draw the three external entities at the top of the board. Ask the class: "What does each entity require?" User needs fast feed loading, photo uploads, search. External Services include push notification providers and CDNs. Time drives daily digests, cache expiration, and scheduled content moderation. Now derive building blocks from these requirements — that's the next slide, but you'll draw it live.
All 7 Building Blocks in Action
Requirement
Entity
Building Block
Technology
Handle upload & feed requests
User Service Flask / FastAPI
Process thumbnails & filters
Time Worker Celery / rq
Cache popular feeds
User Key Value Store Redis
Coordinate background jobs
User Queue Kafka / SQS
Store user profiles & relationships
User Relational DB PostgreSQL
Store actual photo files
User File Store AWS S3
"Find similar photos"
User Vector Database Pinecone / pgvector
One system, all 7 building blocks, driven by 3 external entities.
Draw each row on the board as you walk through it. For each one, trace the chain: entity → requirement → building block → technology. "Users upload photos — that's the User entity. Photos are large binary files — that needs a File Store. AWS S3 is the standard choice for File Store." "Users want fast feeds — User entity. Pre-computed feeds need fast retrieval — Key Value Store. Redis." "Users want to find similar photos — User entity. Similarity search — Vector Database. Pinecone or pgvector." The demo should take about 10 minutes. By the end, the board shows the complete system with all 7 building blocks clearly labeled.
In-Class Exploration
Design a Food Delivery App
Now they apply the complete framework themselves. This exercise is more complex than last week's URL shortener — it touches all 3 external entities and needs most or all 7 building blocks. Same format: small groups, Google Drawings template, build a system diagram.
Your Task: Design a Food Delivery App
Scenario: Design the backend for a food delivery service (like DoorDash / Uber Eats).
The 6 Requirements
Customers browse restaurant menus and place orders
Restaurants receive and confirm or reject orders in real-time
Drivers are matched to orders and their location is tracked on a live map
Payment is processed through a third-party service (Stripe)
Push notifications sent for order status updates (confirmed, picked up, delivered)
Weekly sales reports generated for restaurant partners
Read through the requirements. Point out the external entities embedded in each: Requirements 1-3 are User entity (customers, restaurants, drivers — three different user types!). Requirement 4 is External Service entity (Stripe). Requirement 5 is External Service entity (push notification service). Requirement 6 is Time entity (weekly schedule). This is deliberately more complex than last week — multiple user types, external services, and time-based requirements. Let them work through it.
Exploration Steps
Identify external entities — who/what interacts with this system?Map requirements to entities — which entity drives each requirement?Select building blocks — which blocks satisfy each requirement?Draw the system diagram — show entities, blocks, and data flowMap technologies — which tech would you choose for each block?
Time: ~40 minutes | Individual work
This follows the complete framework they just learned: entities first, then building blocks, then technologies. Post the template link. Walk around and help students individually. Key hints if stuck: "How many different types of users do you have?" (Three: customers, restaurants, drivers). "What happens if Stripe is down?" (Queue + Worker retry). "How do you make the live map fast?" (Key Value Store for driver locations). After 30-35 minutes, bring the class back and have 2-3 students share their designs.
Hints: Think in Entities First
External Entity
Think About...
User Three user types! Customers, restaurants, drivers. Each has different needs.
External Service Stripe for payments, push notification service. What if they fail?
Time Weekly reports. What pattern handles scheduled tasks?
Key Questions
Where do restaurant menus and order data live? (Structured + relationships)
How do you track driver locations in real-time? (Fast updates + reads)
Should payment processing block the order response?
Do restaurant photos need a special storage solution?
Show after ~15 minutes if students need a nudge.
Don't show immediately — let groups struggle productively first. After 15 minutes, reveal these hints. The three user types is the key insight most groups miss initially. Driver location tracking naturally leads to Key Value Store (fast writes and reads of lat/lng). Payment processing naturally leads to Queue + Worker (don't block the order confirmation). Restaurant photos lead to File Store. Weekly reports lead to Time + Worker scheduling. These hints guide without giving away the full design.
What's Next
Week 13: System Design Case Studies — applying the framework to real-world systemsYou now have the complete toolkit:
3 External Entities — what drives your design7 Building Blocks — how you architect the systemTechnology Mapping — which tools you chooseEntities → Blocks → Technologies
Clean ending. They now have all three layers of the system design framework. Next week is about applying it to real-world case studies — analyzing existing systems and designing new ones using the complete framework. Encourage them to start seeing building blocks and external entities everywhere — in apps they use, in systems they read about, in their group projects.