"Feed someone a fish, and you feed them for a day. Teach them to fish, and you feed them for a lifetime. Teach them to start a fishing company, and they can feed the entire world." -The Greater Foundation
Rationale: Numerous times, in my travels as a consultant, I've encountered organizations in which there is no established standard/template for what should be included in an HLD. Quite often (even in organizations that ostensibly have a template), the artifacts that architects and engineers produce devolve into a Wild Wild West of anything-goes. Consistency engenders repeatability - which can help reduce variability in quality - and thus, a worthy goal.
Therefore, the intended purpose in sharing this...at least as a starting point for further customization by a client organization.
STATUS: DRAFT
The goal of an HLD is to facilitate communication and coordination, both within internal teams and organizations - as well as serving as a tool for communication and coordination with external partners.
The HLD provides a consistent format for teams to assemble details - which supports a goal of being able to achieve some level of reuse of design artifacts - and is intended to provide sufficient information to Program/Project Management to be able to plan, estimate, and coordinate large-scale development efforts. Additionally, an HLD servces as an effective mechanism to support Design Review and Architecture Governance efforts.
The ideal place for an HLD to live is in a Wiki or in a Markdown file (i.e. in the git repository for the project)
The target level of detail is to scope the effort, provide sufficient input to the estimation process, and to clearly articulate the How of an approach.
The What should be ideally defined in a collection of User Stories, Use Cases, Feature Requests, etc. - or, minimally, in a Business Requirements Document (BRD).
Investing effort in the creation of the HLD is intended for larger-scoped projects/epics - that have some non-trivial number of unknowns, technical complexity, a high number of coordination points, or extensive external integration/coordination requirements.
fatal: HttpRequestException encountered.
An error occurred while sending the request.
"Allow Bitbucket access tokens to be cast as credentials, and properly handle personal access tokens used as authentication in network requests. Now that Bitbucket access tokens are allowed to be case to credentials, start returning them from OAuthAuthenticator"See the v1.17.1 changelog for Bitbucket related fixes...
"The Site Reliability Workbook is the hands-on companion to the bestselling Site Reliability Engineering book and uses concrete examples to show how to put SRE principles and practices to work. This book contains practical examples from Google’s experiences and case studies from Google’s Cloud Platform customers. Evernote, The Home Depot, The New York Times, and other companies outline hard-won experiences of what worked for them and what didn’t."
"In April 2015, we discussed stale and dirty reads in MongoDB 2.6.7. However, writes appeared to be safe; update-only workloads with majority write concern were linearizable. This conclusion was not entirely correct. In this Jepsen analysis, we develop new tests which show the MongoDB v0 replication protocol is intrinsically unsafe, allowing the loss of majority-committed documents. In addition, we show that the new v1 replication protocol has multiple bugs, allowing data loss in all versions up to MongoDB 3.2.11 and 3.4.0-rc4. While the v0 protocol remains broken, fixes for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite. This work was funded by MongoDB, and conducted in accordance with the Jepsen ethics policy."
"In February 2017, we discussed data loss and fixes in MongoDB 3.4.0-rc3’s v0 and v1 replication protocols. In this Jepsen report, we will verify that MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments. We’ll also discuss MongoDB’s new support for causal consistency (CC) in version 3.6.4 and 4.0.0-rc1, and show that sessions prevent anomalies so long as user stick to majority reads and writes. However, with MongoDB’s default consistency levels, CC sessions fail to provide the claimed invariants"
Caching is a technique that stores a copy of a given resource and serves it back when requested. When a web cache has a requested resource in its store, it intercepts the request and returns its copy instead of re-downloading from the originating server.
NOTE: See the discussion on "Freshness"
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#Freshness
The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.
RFC-7234 Hypertext Transfer Protocol (HTTP/1.1): Caching
- https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
- https://www.incapsula.com/cdn-guide/glossary/cache-control.html
- https://f5.com/resources/white-papers/caching-behavior-of-web-browsers
- https://www.keycdn.com/blog/http-cache-headers/
- https://stackoverflow.com/questions/49547/how-to-control-web-page-caching-across-all-browsers
