scalability   37790

« earlier    

Colin Steele's Blog, 60,000% growth in 7 months using Clojure and AWS

This led to Decision Two. Because the data set is small, we can “bake in” the entire content database into a version of our software. Yep, you read that right. We build our software with an embedded instance of Solr and we take the normalized, cleansed, non-relational database of hotel inventory, and jam that in as well, when we package up the application for deployment.
Egads, Colin! That’s wrong! Data is data and code is code!
We earn several benefits from this unorthodox choice. First, we eliminate a significant point of failure - a mismatch between code and data. Any version of software is absolutely, positively known to work, even fetched off of disk years later, regardless of what godawful changes have been made to our content database in the meantime. Deployment and configuration management for differing environments becomes trivial.
Second, we achieve horizontal shared-nothing scalabilty in our user-facing layer. That’s kinda huge. Really huge.
programming  scalability  database  datastructures 
3 days ago by WimLeers
High availability and scalable reads in PostgreSQL – Timescale
Today PostgreSQL, the fastest growing DBMS of 2017, is more popular than ever. Yet developers often still choose a non-relational (or “NoSQL”) system over PostgreSQL, typically because of one reason…
performance  postgresql  scalability 
11 days ago by geetarista
Applying the Universal Scalability Law to organisations | the morning paper
How to Quantify Scalability: The Universal Scalability Law (USL) - Gunther Update: corrected sign in USL equation - many thanks to Rob Fielding for pointing out the error. TL;DR: The Universal Scalability Law, Little's Law, and Kingman's Formula can tell you a lot about the behaviour of your systems, and also your organisation. From these…
14 days ago by jordan23jy
The Square Root Staffing Law
The square root staffing law is a rule of thumb derived from M/M/m queueing theory, useful for getting an estimate of the capacity you might need to serve an increased amount of traffic.
queueing  theory  scalability  scale 
15 days ago by jordan23jy

« earlier    

related tags

@concept  @project  @reference  agile  amazon  amdahl  analytics  api  architecture  availability  awesome  aws  backend  benchmark  big-data  bigdata  bigquery  bitcoin  blockchain  blog-material  blog  blogs  business  cdn  clojure  cloud  cloudcomputing  cloudpricing  cluster  cockroachdb  coding  comp-sci  compare  comparison  computing  concurrency  conditions  container  crypto  data-warehouse  database  databases  datastructures  db  dba  deeplearning  development  devops  distributed-systems  distributed  distributed_computing  distributedsystem  dopost  economics  engineering  erlang  ethereum  event-driven  facebook  fault-tolerance  filetype:pdf  finnish  foundationdb  framework  from:facebook  from:facebookengineering  go  golang  google  ha  hcb  hosting  http  infrastructure  java  json  kafka  libraries  links  lisp  load-shedding  load-testing  loadbalancing  machine-learning  machinelearning  mango  mcsherry  messaging  metrics  microservices  mit  monitoring  multiple  mysql  netflix  networking  nodejs  nosql  observability  overview  pallet-rack  paper  papers  patterns  performance  pos  postgres  postgresql  pow  power_distribution  pressure  pricing  production  profdev  programming  prometheus  protocol  publisher  pubsub  python  qos  queueing  react  reactive  realtime  reference  reinforcement-learning  relational  reliability  replication  research  risk_management  s3  scala  scale  scaling  security  self_healing_systems  series  serverless  servers  sharding  sidechain  smartcontracts  software-architecture  spring  sql  startups  storage  sync  sysadmin  system-analysis  systemarchitecture  testing  theory  time  timescale  timeseries  toread  triangle  turingcomplete  twitter  uber  usl  verification  warehouse-design  webdev  work 

Copy this bookmark: