From c10bb02a7ddb07b81677f86ee03ccd4c4b4bb338 Mon Sep 17 00:00:00 2001 From: Linus Nordberg Date: Thu, 21 Aug 2014 15:35:11 +0200 Subject: Refine design slightly. --- doc/design.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/design.txt b/doc/design.txt index 472a270..d572543 100644 --- a/doc/design.txt +++ b/doc/design.txt @@ -12,7 +12,9 @@ We have - a cluster of backend nodes with an elected leader which periodically updates the primary db with data from the secondary db's - a number of frontend nodes accepting http requests, updating - secondary db's and reading from [local r/o copy of?] the primary db + secondary db's and reading from local r/o copy of the primary db +- a private key used for signing SCT's and STH's, kept (in HSM:s) on + backend nodes Backend nodes - are either asleep, functioning as storage only @@ -26,7 +28,8 @@ Frontend nodes - reply to the http requests specified in RFC 6962 - write submitted cert chains to their own, single master, secondary database -- have read access to [a local copy of?] the primary database +- have read access to (a local copy of) the primary database +- defer signing of SCT's (and STH's) to backend nodes The primary database - stores cert chains and their corresponding SCT's @@ -43,8 +46,8 @@ The secondary databases - run on frontend nodes - are persistently stored on disk on several other frontend nodes - are typically kept in RAM too -- max size is around 128 MB, based on 10 (3 kB) submissions per second - for an hour +- max size is around 128 MB, based on 10 submissions (รก 3 kB) per + second for an hour Scaling, performance, estimates - submissions: less than 0.1 qps, based on 5,000 submissions per day -- cgit v1.1