Thinking architecture when parking my car ;)

Lately I was parking my car in the city center of my town and found out that ticket parking system has been changed. Instead of old parking meters using coins, new modern ones were introduced – powered by solar panels, taking only card payments and sending parking payment confirmations via e-mail.

At that time I was preparing to #AWS Solution Architect exam and immediately a question came to my mind – how would you architect the IT solution for this… Well usually I don’t have such intriguing thoughts about IT when wandering around, but it happened.

Immediately I thought – this is fairly simple system – we need to store data about car number plate / registration number, amount of payment, transaction ID, selected time period for parking, date … maybe e-mail address of the user to send him payment confirmation if it’s requested. Probably more ‘internal’ data should be also stored as identification of parking meter box etc. , but it should be not much more complicated.

So what would be solution for data storage ? As I was learning AWS technologies immediately DynamoDB and Aurora DB came to my mind. Both are fast, global, high-available solutions that are pretty much recommended everywhere.

However one is #noSQL, second is #SQL database. So ..

At first glance data structure needed for ticket parking system is simple and transactional – we are booking and paying timeslots for parked car. So the record structure would be simple, but … do we really need SQL db ? Maybe noSQL would better fit such scenario – could be faster, ‘lighter’, and still do the job. Such data could be stored using Json or key-value pairs – both supported by #DynamoDB.

?

Anyway I can see following pluses and minuses of both solutions for this particular car parking meter system ->

?

AWS DynamoDB (NoSQL)

Advantages:

• Scalability: DynamoDB is designed to handle large volumes of data and high request rates seamlessly. This is beneficial for a city-wide parking system where data inflow can be unpredictable.
• Performance: DynamoDB offers low-latency responses, ensuring quick access to data, which is essential for real-time applications like ticket parking system.
• Flexibility: The schema-less nature of DynamoDB allows for easy adjustments to the data model without downtime, accommodating changes in the parking system requirements.

Disadvantages:

• Complex Queries: DynamoDB is not ideal for complex queries involving multiple tables or requiring joins. For example, generating detailed reports that combine car registration, payment, and time data might be challenging.
• Consistency: While DynamoDB offers eventual consistency, it might not be suitable for applications requiring strong consistency guarantees.

?

AWS Aurora (SQL)

Advantages:

• Complex Queries: Aurora supports SQL, making it easier to perform complex queries, joins, and transactions. This is useful for generating comprehensive reports and analytics from parking system data.
• ACID Compliance: Aurora ensures strong consistency and transactional integrity, which is crucial for financial transactions and accurate record-keeping.
• Compatibility: Aurora is compatible with MySQL and PostgreSQL, making it easier to integrate with existing systems and tools.

Disadvantages:

• Scalability: While Aurora is scalable, it might not handle extremely high request rates as efficiently as DynamoDB without significant tuning.
• Schema Management: Aurora requires a predefined schema, which can be less flexible when changes to the data model are needed.

?

These are the most important things for me. I think the choice between AWS DynamoDB and AWS #Aurora for storing parking system data depends on the specific requirements of the system:

-> DynamoDB is ideal for applications needing high scalability, low latency, and flexible schema management. However, it may struggle with complex queries and strong consistency requirements.

-> Aurora excels in handling complex queries, ensuring transactional integrity, and integrating with existing SQL-based systems. It may require more effort to scale and manage schema changes.

For a simple ticket parking system, if the primary need is to handle large volumes of data with high performance and flexibility, DynamoDB might be the better choice. If the system requires complex reporting and strong consistency, Aurora would be more suitable.

?

Well, I know it is not definitive answer. Share your thoughts about it, how would you see it ? Would you use noSQL or SQL ? ?I am really curious …

Thanks, Maciej