In this topic

• System Design interview🌳Established

  Allocate specific time slots: 5m for requirements, 20m for high-level design, 15m for deep dive, and 5m for wrapping up. Define requirements and use cases. functional requirements first, and non-functional requirements if…

• Generic vs Concrete software design🌿Growing

  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.…

• Common System Design Patterns🌿Growing

  Database Replication and read replicas. Something something geolocalisation. Postgres has extensions for this.

• Scalability🌿Growing

  A service is scalable if it results in increased performance in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but it can also be to…

• Caching🌳Established

  Cache = trade off speed vs freshness. You can also use the CDN as a cache for api results. Short term. Ok if only a few. Consider how often it changes, how…

• Consistency🌿Growing

  Weak consistency. After a write, reads may or may not see it. A best effort approach is taken. This approach is seen in systems such as memcached. Weak consistency works well in…

• Availability🌿Growing

  Availability patterns. There are two main patterns to support high availability: fail-over and replication. Fail-over. Active-passive. With active-passive fail-over, heartbeats are sent between the active and the passive server on standby. If…

• Consistency vs Availability🌿Growing

  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…

• Cron jobs to fix data vs TTL🌿Growing

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

• Message queues🌳Established

  operations too long for a live server, get feedback to users quickly. reduce load on a live server. when you want the ability to scale differently for different tasks (ie retrievers need…

• Saga choreography vs saga orchestration🌿Growing

  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.

• Batch processing vs stream processing🌿Growing

  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.

• Event Driven System🌿Growing

  Dealing with important events that needs to be stored forever (ie refund events) When you need replayability of events (reprocess historical data) Real-time data processing.

• API Design🌱Seedling
• WebSocket🌱Seedling
• WebSockets vs SSE vs API polling🌿Growing

  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…

• Load Balancer🌳Established

  Single point of contact for user requests. It does health checks for all servers to know if some have issues. Distribution: Round Robin: simple and sequential. IP hashing: allows the same user…

• Reverse proxy🌱Seedling

  A reverse proxy is in front of a server. Intermediary so that clients never talk directly to servers.

• API Gateway🌿Growing

  Api gateways can combine results from different apis into one. Routing: https://www.hellointerview.com/learn/system-design/deep-dives/api-gateway.

• Forward proxy vs Reverse proxy vs API Gateway🌳Established

  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…

• Reverse proxy vs API gateway vs load balancer🌳Established

  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…

• Latency🌱Seedling

  Latency is the time to perform some action or to produce some result.

• Throughput🌿Growing

  Throughput is the number of such actions or results per unit of time. Generally, you should aim for maximal throughput with acceptable latency.

• Adding a dependency to a service adds network overhead🌿Growing

  Server operation time + network overhead. For example, Redis operations are quite fast (couple of ms), there will always be network overhead.

• Distributed configuration management🌿Growing

  Distributed configuration management, zookeeper is a bit outdated but good for this. Example: The API Gateway keeps an open connection to config server and pushes changes straight away. Other not as good…

• Pre-signed urls🌿Growing

  Pre signed urls rather than streaming through api servers with bigger timeouts. This frees servers to do other things, this is supposedly a secure way to get clients direct access to blob…

• Managing sessions🌿Growing

  Session database. django-session. Having a session database rather than storing in the server's memory, allows avoiding sticky sessions. It's best to have sessions expire so that the data gets cleaned eventually. When…

• System Design Primer🌱Seedling

  https://github.com/donnemartin/system-design-primer. They have Anki flashcards too.

• API Authentication🌿Growing

  Maybe not straight user ID in api. Jwt json web token contains signed json data about the user, like what role they have. Every request contains a signature that the server can…

• CDN - Content Delivery Network🌿Growing

  Spread out servers that store copies of content. Page load will be faster as there will be a server closer to the user's location, usually. These usually store and cache content like…

• Connection Pooling🌿Growing

  Connection pooling allows avoiding TCP handshake overhead. Keep some connections ahead.

• Horizontal scaling🌱Seedling

  Horizontal scaling only works if servers are stateless aka, server needs to treat the request as if the user came in here for the very first time.

• How much data is a user in a database roughly🌿Growing

  1KB ish. Some common fields: But what takes most space is database overhead, index, page, etc.

• REST vs GraphQL🌿Growing

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

• Search optimised database🌿Growing

  It usually builds an inverted index for fast querying, like: Tokenization: Tokenization is the process of breaking a piece of text into individual words. This allows you to map from words to…

• Search systems🌿Growing

  Postgres is fine to begin with for basic search. Select where like term. When would somethint else be more relevant ? Wildcard search are slow tho, it'll scan the whole db. But…

• Stateless vs Sticky sessions🌿Growing

  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…

• Sync between databases🌿Growing

  For example between search and main db. When introducing another database, they need to be synced somehow. Easiest: write to both in app code (what if it fails and also makes it…

• Database🌱Seedling