Here is a markdown code of a Design document. Can you provide suggestions on how we can improve this system design? You can add a list of questions to clarify as well:
# Fixed Asset Accounting - Design
### Glossary 
\*\*\*GL\*\* : The Amazon General Ledger for tracking all accounting events in Amazon businesses.\*
\*\*AFFS\*\* : Amazon Financial Foundation Services earlier known as eCFI which owns USL, Flash, Flare etc.
\*\*\*USL or Unified Subledger\*\* : It is a subledger owned by AFFS, which batches the events hourly and sends them to GL for multiple businesses such as prime, retail, alexa etc.\*
\*\*\*CBE or Canonical business event\*\*: This is payload format for events sent to USL.\*
\*\*\*COA or Chart of Accounts\*\* : Also known otherwise as GL\_Segments data which needs to present for all data sent to GL. The 7 segments are company\_code, location, account, cost\_center, project, channel and product.\*
\*\*\*Flash or Financial Ledger and Accounting Systems Hub\*\*: Central Platform owned by AFFS team for onboarding businesses and integrating with them to send updates to GL\*
\*\*\*Flare\*\*: It is a multi-tenant rules authoring and execution engine. Flare is more than a configuration store. Flare serves as a platform that can manage the entire lifecycle of our business rules.\*
\*\*\*SAFE or Simplified Accounting and Folio Engine\*\* : It is a push based audit trail recording system under AFFS which collects all business activities that occur in a system, batch them and persist in the respective business owned S3 account.\*
\*\*\*GTID or Global Transaction ID\*\*: It is used to track events in the AFFS workflows and pipelines until sent to USL\*
\*\*\*Source2USL\*\* : It was created by AFFS to generate reconciliation reports for all clients publishing data to USL via Flash.\*
\*\*Double entry accounting :\*\* It is a method of [bookkeeping](https://en.wikipedia.org/wiki/Bookkeeping) that relies on a two-sided [accounting](https://en.wikipedia.org/wiki/Accounting) entry to maintain financial information

### GL Integration Proposal
[Spursh](https://w.amazon.com/bin/view/FinTech/GeneralLedger/Spursh/JournalIntegrationPlatform) is the central system owned by Close team which ingest JEs (Journal Entries) from various upstream sources and publishes them to OFA-GL in ~~a~~ batches. They allow both automated and manual JE ingestion processes. [USL](https://w.amazon.com/bin/view/AFFS-Home/AFFS-Help/USL/) is one such source for Spursh where it has automated sending JEs to Spursh for various Amazon businesses including retail ordering. [Teller](https://w.amazon.com/bin/view/Main/Teller/), which is the new AP subledger, also uses USL to publish entries to Spursh and subsequently to GL. [Project Amigos](https://w.amazon.com/bin/view/Bill2Pay/Bill2Pay\_Tech\_Vision/) is a similar initiative where they are migrating away from OFA-AR subledger using USL. After going through all the documentation and talking to engineers in the AP, AR domain, we concluded that we could use their learnings and not send JEs to Spursh as an independent source system, and rather send it via USL like Teller and Cimmaron (Amigos). Apart from this there are some other advantages of being part of the USL ecosystem:
1. USL is an Amazon scale solution already processing thousands of transactions per second across multiple geographies and businesses.
2. Newer subledgers onboarding to USL while moving away from OFA can establish a standard workflow for all Subledger to GL interactions thus creating reusable workflows.
3. USL has in built checks and balances to help with validations across different tenants.
4. USL has other tools in its ecosystem which we can leverage (i.e Source2USL for reconciliation)
5. event-based interfaces
Thus, we have decided to go ahead with USL integration for FASL and thus onboarding to Flash which is a pre-requisite for sending data to USL. We would be sending CBE messages to a system called FLARE which would then subsequently publish it to USL. More on how the various components in USL ecosystem communicate with each other can be found [here](https://w.amazon.com/bin/view/AFFS-Home/AFFS-Help/FLASH-Onboarding-Overview/FLASH-Systems/).

#### \*\*Source Systems\*\*
There will be two services sending asset events to the accounting generator. \*\*Asset Service\*\* will be responsible for sending asset create, update, transfer and retire events while \*\*Depreciation Service\*\* will be sending asset depreciation events. 
\*\*\*Asset Service would be sending \_one-off events\_ while depreciation events may be sent in \_batches.\_\*


#### \*\*Asset Accounting Systems\*\*
This comprises of three sub-systems: \*\*Accounting Generator\*\*, \*\*Accounting Reconciliation\*\* and \*\*Accounting Publisher\*\*.
\*\*Accounting Generator\*\* creates a multi-step workflow for each asset event received from the upstream source systems. It transforms the asset event to a CBE, then enriches the event with a GTID by calling reconciliation and then sends it to publisher for sending it to Flash. It also is responsible for state management along with error handling.
\*\*Accounting Reconciliation\*\* enriches CBE events with GTID by calling SAFE to generate unique id for each event. GTID is essential for tracking CBE events inside the Flash systems. The GTID is then used for viewing the event status as well as for reconciliation and reporting for our users.
\*\*Accounting Publisher\*\* sends CBE events to Flash booking service and keeps track of the responses received from Flash along with retry capability for retryable errors (i.e 5XX)


#### Flash/USL Services
AFFS has a suite of services including Flash, Flare, SAFE, Source2USL and USL. 
\*\*Flash\*\* interacts with upstream source systems which send CBEs. It spawns herd workflows to send the event through multiple services before sending it to USL.
\*\*Flare\*\* is the multi-tenant config store which is used by source systems to add business use-case specific metadata in the CBE such as \*business\_namespace, financial\_component\* etc. We would be creating our own model configs for parsing our CBE events.
\*\*SAFE\*\* is a centralized uuid generator for the CBE events as it generates GTID for each CBE by using folio\_id, sequence\_id and timestamp data. Before SAFE, each source system had to create its own uuid generator to create and track the GTIDs.
\*\*Source2USL\*\* helps in generating month close reconciliation reports for the source systems and also provides a dashboard for tracking the events with the help of GTID.
\*\*USL\*\* aggregates CBE events received from all sources including fixed assets and sends them to Spursh for publishing to GL.
다음은 디자인 문서의 마크다운 코드입니다. 이 시스템 디자인을 개선할 수 있는 방법에 대한 제안을 해주시겠어요? 질문 목록을 추가하여 명확하게 설명할 수도 있습니다:# 고정 자산 회계 - 디자인### 용어집 \*\*\*GL\*\* : 아마존 비즈니스의 모든 회계 이벤트를 추적하기 위한 아마존 총계정 원장입니다\*.\*\*AFFS\*\* : USL, 플래시, 플레어 등을 소유한 이전에는 eCFI로 알려진 아마존 금융 재단 서비스.\*\*\*USL 또는 통합 서브레저\*\* : 프라임, 리테일, 알렉사 등 여러 비즈니스를 위해 매시간 이벤트를 일괄 처리하여 GL로 전송하는 AFFS 소유의 서브 레저입니다\*.\*\*\*CBE 또는 캐노니컬 비즈니스 이벤트\*\*: USL로 전송되는 이벤트의 페이로드 형식입니다\*.\*\*\*COA 또는 계정 명세서\*\* : GL로 전송되는 모든 데이터에 대해 제시해야 하는 GL\_Segments 데이터라고도 합니다. 7개의 세그먼트는 회사\_코드, 위치, 계정, 비용\_센터, 프로젝트, 채널, 제품입니다.\*.\*\*\*플래시 또는 재무 원장 및 회계 시스템 허브\*\*: 비즈니스를 온보딩하고 GL에 업데이트를 전송하기 위해 비즈니스와 통합하기 위한 AFFS 팀 소유의 중앙 플랫폼\*.플레어\*\*\*: 멀티테넌트 규칙 작성 및 실행 엔진입니다. Flare는 구성 저장소 그 이상입니다. Flare는 비즈니스 규칙의 전체 수명 주기를 관리할 수 있는 플랫폼 역할을 합니다\*.\*\*\*안전 또는 단순화된 회계 및 폴리오 엔진\*\* : 시스템에서 발생하는 모든 비즈니스 활동을 수집하여 일괄 처리하고 각 비즈니스 소유의 S3 계정에 보존하는 AFFS의 푸시 기반 감사 추적 기록 시스템입니다.\*\*\*\*\*GTID 또는 글로벌 트랜잭션 ID\*\*: USL\*로 전송될 때까지 AFFS 워크플로우 및 파이프라인에서 이벤트를 추적하는 데 사용됩니다.\*\*\*Source2USL\*\* : 플래시를 통해 USL에 데이터를 게시하는 모든 클라이언트에 대한 조정 보고서를 생성하기 위해 AFFS에서 생성되었습니다\*.\*\*복식부기 :\*\* 재무 정보를 유지하기 위해 양면 [회계](https://en.wikipedia.org/wiki/Accounting) 입력에 의존하는 [부기](https://en.wikipedia.org/wiki/Bookkeeping) 방식입니다.### GL 통합 제안[Spursh](https://w.amazon.com/bin/view/FinTech/GeneralLedger/Spursh/JournalIntegrationPlatform)는 Close 팀이 보유한 중앙 시스템으로, 다양한 업스트림 소스로부터 JE(저널 엔트리)를 수집하여 ~~일괄적으로 OFA-GL에 게시합니다. 자동 및 수동 JE 수집 프로세스가 모두 가능합니다. [USL](https://w.amazon.com/bin/view/AFFS-Home/AFFS-Help/USL/)은 소매 주문 등 다양한 아마존 비즈니스를 위해 Spursh에 JE를 자동으로 전송하는 소스 중 하나입니다. 새로운 AP 서브 원장인 [Teller](https://w.amazon.com/bin/view/Main/Teller/)도 USL을 사용하여 Spursh에 항목을 게시하고 이후 GL에 게시합니다. [프로젝트 아미고스](https://w.amazon.com/bin/view/Bill2Pay/Bill2Pay\_Tech\_Vision/)도 비슷한 이니셔티브로, USL을 사용하여 OFA-AR 서브원장에서 마이그레이션하고 있습니다. 모든 문서를 검토하고 AP, AR 영역의 엔지니어들과 이야기를 나눈 후, 우리는 그들의 학습을 활용하여 JE를 독립적인 소스 시스템으로 Spursh에 보내지 않고 Teller 및 Cimmaron(Amigos)과 같이 USL을 통해 보낼 수 있다는 결론을 내렸습니다. 이 외에도 USL 생태계의 일부가 되면 몇 가지 다른 이점이 있습니다:1. USL은 이미 여러 지역과 비즈니스에서 초당 수천 건의 트랜잭션을 처리하는 Amazon 규모의 솔루션입니다.2. 신규 서브레저가 OFA에서 벗어나 USL에 온보딩하면 모든 서브레저와 GL 간의 상호작용에 대한 표준 워크플로우를 구축하여 재사용 가능한 워크플로우를 만들 수 있습니다.3. USL은 다양한 테넌트 간의 검증을 지원하기 위해 견제와 균형을 내장하고 있습니다.4. USL은 생태계에서 활용할 수 있는 다른 툴을 보유하고 있습니다(예: 조정용 Source2USL).5. 이벤트 기반 인터페이스따라서, 우리는 FASL을 위한 USL 통합을 진행하기로 결정했고, 따라서 USL로 데이터를 전송하기 위한 전제 조건인 플래시 온보딩을 진행하기로 결정했습니다. 우리는 FLARE라는 시스템으로 CBE 메시지를 전송하고, 이후 이를 USL에 게시하게 될 것입니다. USL 생태계의 다양한 구성요소들이 서로 통신하는 방법에 대한 자세한 내용은 [여기](https://w.amazon.com/bin/view/AFFS-Home/AFFS-Help/FLASH-Onboarding-Overview/FLASH-Systems/)에서 확인할 수 있습니다.#### \*\*소스 시스템\*\*에셋 이벤트를 어카운팅 생성기로 전송하는 두 가지 서비스가 있습니다. \*\*자산 서비스\*\*는 자산 생성, 업데이트, 이전 및 폐기 이벤트를 전송하고 \*\*감가상각 서비스\*\*는 자산 감가상각 이벤트를 전송할 것입니다. \*\*\*자산 서비스는 \_일회성 이벤트\_를 전송하는 반면 감가상각 이벤트는 \_배치\_로 전송될 수 있습니다.#### \*\*자산 회계 시스템\*\*이 시스템은 세 가지 하위 시스템으로 구성됩니다: \*\*회계 생성기\*\*, \*\*회계 조정\*\* 및 \*\*회계 게시자\*\*.\*\*계정 생성기\*\*는 업스트림 소스 시스템에서 수신한 각 자산 이벤트에 대해 다단계 워크플로를 생성합니다. 자산 이벤트를 CBE로 변환한 다음, 재조정을 호출하여 GTID로 이벤트를 보강합니다.