我正在尝试设计一个通用的作业调度程序来扩展我的架构知识和在面试中思考系统设计问题的能力。到目前为止，我想出的内容如下。你能指出我应该在哪里工作以全面解决这类问题吗？
我在网上阅读了很多资源，但在前进时需要一些具体的指导。
为 X 公司（当今最大的技术公司之一）设计一个通用的作业调度程序。
用例
创建/读取/更新/删除作业
调查过去运行的作业（作业类型、花费的时间、详细信息）
约束
每秒将在系统上运行多少作业？
= 用户数/小时的作业数 + 机器数/小时的作业数
= 1m * 0.5 /天/24/3600 + 1m/50*20/24/3600
~= 12 个作业/秒
系统需要存储多少数据？
推理：我只是存储作业执行细节，实际工作（脚本执行）是在其他机器上完成的，收集的一些数据是结束时间、成功/失败状态等。这些> 都可能只是文本，可能带有用于说明目的的图形。我将通过作业调度程序将 > > 所有作业的数据存储在系统中（即过去 10 年）
=（设置作业详细信息的页面大小 + 收集的有关作业的数据大小）* 作业数 * 365 > 天 * 10 年 = 1 MB * 900 000 * 365 * 10
~= 3600 000 000 MB
= 3600 000 GB
=3600 TB =3.6 PB
抽象设计
根据上面的信息，我们不需要太多的机器来保存数据。我会将设计分解为以下内容：
应用层：服务请求，显示 UI 细节。
数据存储层：就像一个大哈希表：存储键值对的映射（键是按日期时间组织的作业，它们运行，而值将显示这些作业的详细信息）。这是为了能够轻松搜索历史和/或计划的作业。
瓶颈：
流量：12 个作业/秒并不太具有挑战性。如果这个峰值，我们可以使用负载平衡器将作业分配到不同的服务器以执行。
数据：在 3.6 TB 时，我们需要一个可以轻松查询的哈希表，以便快速访问已在应用程序中执行的作业。
缩放抽象设计
此作业调度程序的本质是每个作业都具有以下几种状态之一：待处理、失败、成功、终止。无业务逻辑 返回少量数据。
为了处理流量，我们可以有一个每秒处理 12 个请求的应用程序服务器和一个备份，以防万一失败。将来，我们可以使用负载均衡器来减少发往每台服务器的请求数量（假设>1台服务器正在生产中）这样做的好处是减少请求/服务器的数量，提高可用性（以防一台服务器发生故障，并且很好地处理峰值流量）。
对于数据存储，要存储 3.6 TB 的数据，我们需要几台机器将其保存在数据库中。我们可以使用 noSQL 数据库或 SQL 数据库。鉴于后者具有更广泛的使用和社区支持，这将有助于解决问题并且目前被大公司使用，我会选择 mySQL db。
随着数据的增长，我会采用以下策略来处理它：
1）在哈希上创建唯一索引
2) 通过添加更多内存垂直扩展 mySQL 数据库
3）通过分片对数据进行分区
4）采用主从复制策略，主从复制，保证数据冗余
结论
因此，这将是我对作业调度程序组件的设计。