Learn how to design systems at scale and prepare for system design interviews.
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
CATF44LT7C-eyJsaWNlbnNlSWQiOiJDQVRGNDRMVDdDIiwibGljZW5zZWVOYW1lIjoiVmxhZGlzbGF2IEtvdmFsZW5rbyIsImFzc2lnbmVlTmFtZSI6IiIsImFzc2lnbmVlRW1haWwiOiIiLCJsaWNlbnNlUmVzdHJpY3Rpb24iOiJGb3IgZWR1Y2F0aW9uYWwgdXNlIG9ubHkiLCJjaGVja0NvbmN1cnJlbnRVc2UiOmZhbHNlLCJwcm9kdWN0cyI6W3siY29kZSI6IklJIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiQUMiLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJEUE4iLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJQUyIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IkdPIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiRE0iLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJDTCIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IlJTMCIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IlJDIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiUkQiLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJQQyIsInBhaWRVcFRvIjoiMjAyMC0wMS0wOCJ9LHsiY29kZSI6IlJNIiwicGFpZFVwVG8iOiIyMDIwLTAxLTA4In0seyJjb2RlIjoiV1MiLCJwYWlkVXBUbyI6IjIwMjAtMDEtMDgifSx7ImNvZGUiOiJEQiIsI
| #!/usr/bin/env bash | |
| # | |
| # Bootstrap script for setting up a new OSX machine | |
| # | |
| # This should be idempotent so it can be run multiple times. | |
| # | |
| # Some apps don't have a cask and so still need to be installed by hand. These | |
| # include: | |
| # | |
| # - Twitter (app store) |
| version: "3" | |
| services: | |
| sonarqube: | |
| image: sonarqube | |
| expose: | |
| - 9000 | |
| ports: | |
| - "127.0.0.1:9000:9000" | |
| networks: |
I'm going to walk you through the steps for setting up a AWS Lambda to talk to the internet and a VPC. Let's dive in.
So it might be really unintuitive at first but lambda functions have three states.
- No VPC, where it can talk openly to the web, but can't talk to any of your AWS services.
- VPC, the default setting where the lambda function can talk to your AWS services but can't talk to the web.
- VPC with NAT, The best of both worlds, AWS services and web.
| #!/bin/bash | |
| set -e | |
| AAPT="/path/to/android-sdk/build-tools/23.0.3/aapt" | |
| DX="/path/to/android-sdk/build-tools/23.0.3/dx" | |
| ZIPALIGN="/path/to/android-sdk/build-tools/23.0.3/zipalign" | |
| APKSIGNER="/path/to/android-sdk/build-tools/26.0.1/apksigner" # /!\ version 26 | |
| PLATFORM="/path/to/android-sdk/platforms/android-19/android.jar" |
| ### java -jar | |
| java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8001,suspend=y -jar target/cxf-boot-simple-0.0.1-SNAPSHOT.jar | |
| ### Maven | |
| Debug Spring Boot app with Maven: | |
| mvn spring-boot:run -Drun.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8001" |
Below are a set of best practices that I recommend for most customers. This information is based on my experience helping hundreds of Azure Redis customers investigate various issues.
- Use Standard or Premium Tier for Production systems. The Basic Tier is a single node system with no data replication and no SLA. Also, use at least a C1 cache. C0 caches are really meant for simple dev/test scenarios since they have a shared CPU core, very little memory, are prone to "noisy neighbor", etc.
- Remember that Redis is an In-Memory data store. Read this article so that you are aware of scenarios where data loss can occur.
- Configure your client library to use a "connect timeout" of at least 10 to 15 seconds, giving the system time to connect even under higher CPU conditions. If your client or server tend to be under high load