Trade-off explorer

An image or a song would be immutable data.
The access pattern for those is a lot of reads, very few writes.
These would be best stored in a system where it's easy to read and stream and store in easily horizontally scalable blob storage systems like AWS S3.
Metadata like where the user stopped listening to the song gets written more often, or ability to search needs a different kind of database.

Memcached is supposedly a bit faster as it is multi threaded.
Redis has better support of more data types.
Redis has optional disk persistence.

MySQL is thread per connection, where PostgreSQL is process per connection.
MySQL is seemingly faster for lots of concurrent simple reads. PostgreSQL takes up more memory, but handles complex queries better with its planner in its own process.

PostgreSQL has many extensions, and good support for JSON for flexible document storage.

Apparently MySQL is slightly more permissive with its SQL syntax.

Amazon DynamoDB and Amazon DocumentDB are both fully managed NoSQL databases on AWS, but they are built for entirely different data models and architectural needs.

• Choose DynamoDB if you need predictable, single-digit millisecond latency at virtually limitless scale, have well-defined access patterns, and want a truly serverless database.
• Choose DocumentDB if your data features complex, deeply nested JSON structures, you require powerful ad-hoc queries or aggregation pipelines, or you are migrating an existing MongoDB workload.

When I'd use DDB:

• if key value access is enough
• I need heavy write (more than 10k writes per second)
• automatic and managed sharding

What you're giving up with postgres:

• relations and joins: in ddb, you have to manage constraints yourself or duplicate documents
• ad-hoc querying: harder to find specific data or debug without doing sequential scans
  • you lose ability to do aggregations like group by or avg
• transactions
• strong consistency
• cost predictability (some ddb queries can be expensive as you pay per query)

When is GraphQL is a good idea?
When flexibility of what data to retrieve is important, but it is possibly rarely worth the overhead.

Set long timeouts intentionally, services should be fast, unless it is purposefully (can't do otherwise) slow.

WebSockets is 2 way open connection.
SSE (Server Sent Events) is one way.
API usually have a timeout of 30-60 seconds, configured by an outside system, often.

If the operation you're doing will take more than 5-10 seconds, it's best to make it async.
APIs can be done async if you poll, or you can keep an open connection

When is polling better? Why is it more simple? Doesn't need to keep the connection open? Which one has less load on server?

What worked for others in other scenarios might not work for you.

Concrete system design discussions are best done by the people involved in working in the system. It'll be more specific.

This is why the "architect" role is not that good, because their role is to create generic system design. Sean goes as far as:

architects can both claim credit for successes (after all, it was their design) and disclaim failures (if only those fools had followed my design!)

Generic system design is helpful for:

• new systems
• tie-breaking between decisions for existing systems

Consistency = every read gets most recent write
Availability = the system responds even if it's not the most recent data

For example with Ticketmaster, consistency is way more important, but for rate limiters, availability is more important.
It could be different even within Ticketmaster, for example for search, availability is more important, but for booking, consistency is more important

Think of read vs write ratio. People search more than they buy tickets

Depending on the data you need to fix, if it's simply releasing something, then a TTL on a row is better.

Either each service triggers the next one, or there is an orchestrator managing the whole thing.
Queen was an orchestrator whereas in PIMS, it was choreography style, retriever triggers transformer, etc.

In old existing product data, it was stream processing, processing one spider item at a time.
whereas in dogs, it was batch processing, processing 'big' sqlite files

Forward proxy: next to the client before reaching internet
Reverse proxy: server side to go to the right server
API gateway: reverse proxy that does more than routing. it handles auth, rate limiting and other things before going to the right API

A forward proxy sits next to the client. Your laptop sends a request, the proxy forwards it out, and the destination never sees your real IP. Corporate networks use this to enforce policy, block sites, and cache traffic.

A Reverse proxy sits next to the server. The client has no idea how many machines are behind it. The proxy decides who handles the request, terminates TLS, and keeps your backend off the public internet. NGINX and HAProxy are commonly used here, typically paired with a Load Balancer in front.

An API gateway is a reverse proxy that does more than route traffic. It also handles auth, rate limits, API keys, versioning, and request shaping. Without it, each microservice has to implement its own version of validation, throttling logic, and request logging.

A forward proxy represents the client, a reverse proxy represents the server, and an API gateway is what you add when ten services need the same authentication and rate limiting rules applied consistently.

In most real systems, all three are running at different layers. The forward proxy filters outbound traffic, the reverse proxy fronts the application servers, and the API gateway sits in front of your APIs to enforce policies before requests reach them.

Reverse proxy
An API gateway is a specialized type of reverse proxy

The easiest way to differentiate them is by their core focus: a load balancer focuses on scale, a reverse proxy focuses on security and optimization, and an API gateway focuses on application logic and API management.

Direct Comparison

1. Reverse Proxy (The Shield & Booster)

A reverse proxy sits in front of a web server to shield its identity, optimize performance, and handle incoming requests. It acts as an intermediary so clients never talk directly to your actual application servers.

• Main Job: Privacy, security, and offloading repetitive tasks.
• Key Capabilities:
  • SSL/TLS Termination: It handles the heavy encryption/decryption work so backend servers don't have to.
  • Caching: It stores copies of popular static content (like images or CSS) and serves them instantly without hitting your backend.
  • Anonymity: It hides the IP addresses and structures of your internal infrastructure from the public internet.

2. API Gateway (The Smart Concierge)

An API gateway is a specialized type of reverse proxy designed specifically for modern microservices architectures. It doesn't just pass requests along; it inspects, translates, and manipulates them based on application rules.

• Main Job: Orchestrating API requests and enforcing business logic at the edge.
• Key Capabilities:
  • Request Routing / Composition: It can take a single request from a mobile app, fetch data from three separate backend microservices (e.g., Users, Inventory, and Shipping), combine the data, and send back one clean response.
  • Authentication & Authorization: It checks if a user's API token is valid before letting the request reach any microservices.
  • Rate Limiting & Throttling: It blocks users who try to spam or abuse specific endpoints (e.g., limiting a user to 60 requests per minute).
  • Protocol Translation: It can convert an incoming REST request into an internal gRPC request.

How They Work Together

In a large production environment, you will often see all three layered together to form a robust architecture:

1. A Load Balancer sits at the very front to split incoming traffic across multiple instances.
2. The traffic hits a Reverse Proxy to strip away SSL encryption and handle basic caching.
3. The request is passed to the API Gateway, which authorizes the user's API token and routes them to the correct backend microservice.

Sticky session means it'll only work if the user has time come back to a specific server.
Stateless means server needs to treat the request as if the user came in here for the very first time

aka Sponsoring

juniors execute, seniors question.

Frontier models are good by themselves (ie Claude Code)
Single agent (could) need more human in the loop to review, where multi agent could review itself.